Jotne, app password is “app password”. Not for web. The “limited use” is a feature, like jbl42 explained.
A password may be leaked no matter how many characters it has, or how wide the range of characters it uses. The post I was responding to implied that the all-lowercase 16-character limit was a problem, but raising those limits don’t alter your objection. My only point is that these passwords’ resistance to offline massively-parallel attacks is likely to suffice, since the device in question is likely to be retired before the ~14 years the page I linked to predicts.
Realize also that massively-parallel offline attacks aren’t the norm. In this case, it would mean that Google’s hashed password store was compromised, which doesn’t seem likely. For online connection rate limited attacks, even 8 characters may be enough.
It’s important to consider that these GMail application-specific passwords are machine-generated random ones. Much of the advice recommending long passwords carries the implication that humans will be making them up. With a random password, the entropy in each character is as close to ideal as the PRNG permits. (Roughly 5 bits of entropy for all-lowercase.) With a human-generated password, effective entropy can drop into the 1-2 bits per character range.
That is what 2nd factor authentication solves
Certainly, but that’s also precisely why Google has this feature: they know not all applications of email are from humans, who can complete the MFA challenges. Automated senders require fixed passwords. Thus Google’s solution: make them long (enough), random, and per-application to reduce the risks associated with fixed passwords.
not to use mail for such things
That is indeed becoming a common option. It’s why I prefer off-router syslog to the cutesy “email the logs every night” stuff you see around RouterOS occasionally.
Guys,
stop this Gmail-thing conversation on the topic of specific ROS version. It’s completely out of scope and interest of many.
True. I only wanted to mention it because it apparently motivates other serviceproviders to drop this form of authentication as well. It still works for gmail and it serves a purpose, but don’t be surprised when you receive the announcement that its days are numbered.
How can you not test the RB3011 SFP bug before releasing this into “stable”?
Very fun downgrading routers at remote sites today!
How can I go from 6.x to 7.2.x? If I set channel=upgrade it will chose 7.3 as of now.
Should I just manually upload 7.2.x NPK and reboot to get to 7.2.x?
Has anyone tested RB3011 and SFP with 7.4 beta?
Is there something you need in v7 that means you have to upgrade? If no rush I would wait for a real long-term build in v7 that support good upgrading from 6 to 7.
OlofL, 7.3 in general is much better than 7.2.x except this one issue with SFP on RB3011. We will have a hotfix later today. Don’t install 7.2 just for this
This sounds so stupid. Its not “much better” for me. It broke everything.
So basically you make 7.3 release candidate.
Wait a few days and see how much forum is spammed.
If less than 5 new angry topics - move that exact release into “stable” channel.
Yes, that seems to be how it works. But usually between the last rc and the final release there are a couple of “last minute fixes” as well… at least it seems.
Also the time the last rc spent in testing was very short. If the 3011 SFP issue was there as well in that version, it would probably have come up when waiting a little longer before stable release.
Fortunately in another topic Normis now said they were looking at these schemes. It really has to be done more carefully.
Ideally what we want to see is a release of a version 7.3 [stable] that has the same date/time stamp of the last rc (in this case 7.3rc2). But there are 4 days between them, who knows what happened in those 4 days that makes the 7.3 different from 7.3rc2.
Trying to upgrade a cAPac from 6.49.6 to 7.3.1 and getting a “not enough space for upgrade” error (as well as warnings that 7.3.1 dhcp and wireless packages are broken). Try to upgrade to 7,3 and I still get the “not enough space for upgrade” error, but at least there are no complaints about broken packages.
I’ve tried resetting it and uninstalling unwanted packages, but to no avail. Is the only way to upgrade this to netinstall it?
You probably at one time have switched to separate packages instead of the combined package. That causes this problem. It is best to netinstall.
Make a backup of anything on .backup and .rsc format
save routeros-…-7.3.1.npk on your system, not on routerboard
extract from 6.48.6 extra packages only system-…-6.48.6.npk and copy it on routerboard
on System / Packages select uninstall to all except system, do not reboot, then click on downgrade,
now reboot
after downgrade put back 7.3.1, reboot, upgrade bios on System / Routerboard and import back the text .rsc file, section by section.
OR
backup all on external disk and
netinstall 7.3.1 selecting on netinstall 7.3.1 “Keep old configuration”
That worked perfectly. Thank you.