When it comes to composition and length, passwords mostly don't matter
techcommunity.microsoft.com
techcommunity.microsoft.com
I deal with relatively higher volumes of information that must remain secure.
With google, I have hardware authentication device and 10 codes.
Every 30 days or so it asks me to plug in the hardware device. Randomly it asks me more often - I have no idea why but no objection. My password is secure as well and only used on google but THANKFULLY I do not need to change it all the time and so I don't have to write it down. This feels like a reasonably secure approach.
No SMS text option. The idea that your phone number is the key that allows you to reset all your passwords (no matter how complicated / securing no matter how much sensitive info) is ridiculous.
"Two is one and one is none," as the Special Operations folks will explain.
Sure, the math is squirrely; but the sentiment is real.
Agreed. My Twitter account was recently hacked thanks to T-Mobile's incompetence. [0]
[0]: https://medium.com/@simon/mobile-twitter-hacked-please-help-...
They stole your SIM. SMS option was now in their control.
SMS is not a secure 2FA option. sure its better than not having 2FA but only a little better.
I'm becoming convinced this is a pervasive fallacy (perhaps not for all users in all cases, but for many). Having SMS as your 2FA potentially makes your phone, phone line, and everything linked to it an attack target. So you might lose a heck of a lot more than you would if they were all unlinked. It depends kind of on what your current security practices are, but I think for many it can well be indirectly risking more damage than it's preventing.
Most hackers never have physical access to people. The intersection between the 2 sets - hackers and pickpockets - approaches zero.
That they may have friends who they accidentally do this for?
That they may not detect the fake ID some random person with your name and number shows them?
Etc etc. None of this requires getting your phone.
Only if the provider doesn't decide to be "helpful" and start allowing password resets via SMS on your 2FA number.
The ability to do this would not mitigate Microsoft’s responsibilities here, but at least it would allow some people to help themselves.
That's an interesting point. Maybe an unlisted burner that you don't use for anything else could be your SMS backup number. At least that adds one small layer of security.
It's like being in an episode of The Wire just to stay semi-secure online ;-).
My Account > Security & Privacy > Additional Security Verification > Update Your Phone Numbers Used for Account Security
And then setting the preferred method to "use verification code from app". Once you finish setting up the authenticator app you can delete your phone number from the 2fac list.
At the end of that process you should be left with only having the app authenticator as a 2fac option.
See https://docs.microsoft.com/en-us/azure/active-directory/user... for some details, but the MSFT documentation on this isn't very good in general.
If You are able to remove it, I’m wondering if there is some sort of policy or limitation our VAR is adding to our instance.
edit - added quotes to the error message
Not sure how that works if they (Microsoft) don’t have your phone number.
(password AND SMS) OR (password AND app) OR SMS --> Get in!
Then it would be obvious that the password is sort of redundant and it's really less secure than 1FA. It would also be clear what you have to lose to be locked out yourself. Only having 2 factors is not great because that's twice as many ways to get locked out. You really need 3 or more but it's never clear if that's reducing security to 1FA level or not because they don't clearly show you what the account recovery options are.
"Passwords don't matter, as long as your password isn't in the top few dozen common ones, it's not in any credentials breach accessible to attackers, it's longer than 8 characters or so, and you don't reuse it."
That was a lot of criteria that seemed to matter, if you ask me.
It would be incredibly naive to think that one account has significantly more value than another because once you are in the system, your ability to compromise it skyrockets -- no matter what kind of account you have. Sure, you're probably trying to work your way up to administrative account level, but there are so many more local attacks than remote attacks that it isn't even funny.
I'm not sure there is an accusation that the article is being naive in this way or not (there seems to be some confusion). It would be really shocking to see a blog post from Microsoft talking about security that would say something so naive. But as far as I can tell, they didn't.
That’s a key difference between hypothetical and practical security – your attacker will only do really wacky, creative stuff you hear about at conferences (or wherever) when there’s no easier way and the target of the attack justifies the extra effort.
Emphasis mine.
Just with one or two minor tweaks the analysis falls flat.
For instance, they seem to only look at mass scale script kiddie sprays, a targeted attack will likely not use the mentioned passwords. As one can come up with much better and more likely to succeed candidates.
It also entirely misses attacks that come from a more privileged position (like in Windows directly authenticating to the domain controller) where an adversary can do millions of attempts in short time because of typical monitoring gaps.
The backup/recovery options are just terrible. You either print out a sheet of "one time codes" (which I need to not lose forever), my phone simply needs to never break, or I need to configure an insecure recovery account (creating a whole chicken/egg problem).
This is in no way mitigated by using physical keys either. Which can also be lost/broken/stolen/etc. You still need recovery/backup.
Plus a ton of vendors allow customer support to trivially turn off MFA via social-engineering, so what is the point? If people want MFA to be more common, make the lifecycle better. Right now the backup/recovery situation is all over the place and frankly bad.
But I didnt realize I would have to reset up every single code on authenticator on the new phone. When you have a lot of accounts it's pretty obnoxious even with recovery codes. It didnt help that google support directly told me that they would be automatically be restored on the new phone along with the rest of the settings.
The public key is different for each enrollment, on purpose to deliver pseuonymity. If you enable U2F for Facebook, and then I borrow your Security Key and also use it to enable U2F for Facebook, although obviously that key will now work for either of us for signing into Facebook, Facebook don't learn that it's the same device. If Microsoft compares the data from GitHub to their own U2F data, they don't learn anything about whether GitHub users are also live.com users from that data, none of it correlates.
The hardware today doesn't have a "base private key" (or public key) in the sense you mean. I feel like you're thinking about this like it's RSA, which it really isn't. RSA is weird because Encrypt and Sign are related operations, that is not how most things work. So you'd have to use key agreement plus symmetric crypto, and you'll struggle to fit everything into the current data structure sizes.
You've correctly identified most of the tricky bits: the real algo involves key agreement plus symmetric crypto, it's a tight fit size-wise, and not all hardware has the necessary capabilities. However I think you're wrong about the conclusion. Can't say for sure though, as I didn't produce a working prototype. If you actually see this and want to discuss it in more detail you can find my email in my profile.
Or if you're really worried about getting locked out, maybe three options.
This had me thinking about off-site backups and eventually my mind got to steganography (as the trust placed in the off-site custodian is a lot). It's a shame backup codes don't match phone numbers in terms of digit count, that would make keeping a book of them more easy to obscure, or even leaving a couple in your synced contacts as unassuming names.
This is not the case if you are using a corporate controlled account
That's fine and dandy until you need to manually type it in somewhere (e.g. reading it from your phone, typing it in on another device). Has this guy ever even used a password manager? He understands how they work in theory, but in practice it's not always quite so clean. Humans will be human.
$ head -c 100 /dev/urandom | sha256sum
Same pain as you any time I have to type the password in someplace I don't have my password manager installed, but with the advantage that its just [0-9a-f]. I figure with that many characters there's no need to use the full character set.
Also honestly just tend to use weaker passwords on things I'll need to log into on other machines. Usually those are accounts I don't care as much about anyway.
I'm sure there are similar schemes for other devices (Chromecast/FireTV?). But when the TV itself is "smart", I bet it's infuriating.
Hulu does this much better though. They display a hulu.com shortlink on the TV app that you type into your browser on a computer, login if you aren't already, and click a button to authorise the TV.
But is Apple’s speech-to-text feature (like on the iOS keyboard or in tvOS) recorded? If not, I’d venture to say I’m (currently) OK doing that with Apple services. They’ve prioritized security and privacy admirably.
> use more than 8 characters, or use a password manager if you are really nervous
Also the article mentions that pw managers will get you long passwords, which will protect against brute force, but doesn't really mention the more significant benefit, that they protect against password reuse. Not to mention they're far more convenient than trying to remember strong passwords.
So don't use a PW manager only if you're really nervous. Just use one, full stop.
(But yeah, set password length at something like 13-14 characters. More than that doesn't provide any real world benefit, and there will occasionally be cases where you have to type it in. Plus you'll hit fewer snags with poorly designed systems enforcing max pw length.)
And all modern browsers ship with one included, so it’s not like it’s hard to get started.
QR codes, Samsung.
Not sure how common of a feature that is with most password managers, but I find it incredibly useful. For reference in case anyone wants to use it, my generator works by running scrypt on a master password as well some identifier for the site.
I'd be much more interested what that percentage is when you only consider people who use password managers. (Which is not to imply that MFA isn't good.)
You'd probably mostly catch password managers and people copy-pasting passwords though. If you had per-user fingerprints also people typing on a new device...
KISS.
at that point you might as well outsource that sort of fingerprinting/behavior analysis to some service like recaptcha.
- Hackers haven't spent time breaking it
- It doesn't raise the same level of privacy concerns
- You control the UI (though recaptcha3 gives you that) and have greater insight into what the score means and why
The icing on the cake is that when I called to complain about it, the support agent insisted in very sombre tones that it was a measure to stop keyloggers. I don't use that bank any more.
not an issue on firefox because you can toggle the dom.event.clipboardevents.enabled to false, and sites won't be able to hijack your pastes.
Like you, whenever I run into sites that do weird things like that, I always find it hard to shake a bit of suspicion about how their backend is implemented (or not, depending on the case). For instance, when they start rejecting characters like "%" or "'" which have special meaning in SQL. I can't help but wonder if they're storing things in plain text.
I've run into at least two vendors I can think off the top of my head that limit what characters you can use for a password. That always makes me uneasy, and I don't buy anything from them on principle. Who knows what else they're doing that's not immediately obvious.
An important thing to remember here is that MFA works with a password. Otherwise, that 99% goes down dramatically because I can just steal your phone/Yubikey/whatever.
This article isn't suggesting that we get rid of passwords. It's suggesting that the energy we spend making sure that passwords are good would be better spent encouraging users to enable MFA.
In other words, having two relatively weak authentication mechanisms that must be used in tandem is still better than having one strong authentication mechanism.
If this were true your car would probably get stolen a lot more often. You're less secure from targeted attacks from people who know you IRL but that's a lot rarer than the attacks you'll actually encounter.
But aren't wallet/phone thefts relatively common?
> You're less secure from targeted attacks from people who know you IRL
I'm also not completely certain this is true. If a YubiKey is the only thing securing most people's accounts, I don't need to target you. I can walk into a coffee shop, or locker room, or office and steal as many YubiKeys as I can find.
And then I can check later whether or not any of them are linked to bank accounts. I don't know the stats; are most petty wallet/phone thefts targeted?
There is little overlap between petty thieves and people trying to get into a particular target’s account.
But isn't that the point? There's little overlap because right now we have a multi-factor system where stealing one part of the authentication mechanism from a random person in the street isn't enough to get into their account.
If everyone's account is secured with just a YubiKey, then you don't have to target a specific person. What's to prevent any petty thief from grabbing a bunch of wallets and/or YubiKeys, walking into a library, and just checking a few of the most common banks to see if any of them log in?
Maybe I'm missing something? It's not clear to me why an MFA attack would ever need to be targeted in a world without passwords. I guess maybe you're hoping that petty thieves can't figure out your username? But that's just treating your username like a password.
For a lot of bank accounts, your username will be some variant of your first and last name, which is helpfully printed on the drivers license in the wallet I just stole. I don't need to know who you are beforehand.
https://techcommunity.microsoft.com/t5/Azure-Active-Director...
If you're logging in from your phone anyway, then it's not really a second factor, so it's meaningless.
If you're not, then your phone might be unavailable or charging or something, so you're locked out.
And if someone else gets hold of your phone, they can now easily log in, so it increases the attack area.
MFA is a bad idea. Biometrics are a bad idea (for similar reasons). Unique passwords (handled with a password manager) are still by far the best solution that we have. Adding epicycles is not the answer. Improving the UX and handling of passwords is the way forward.
> Some guidance says to ban all passwords on this list. Try that and see how successful your users are at choosing passwords at all.
We're doing that. We don't let you choose any password that's been discovered in a prior breach.
Did Microsoft implement the same thing and discover a high rate of users bouncing off the registration page?
If that’s happened thousands of times, sure, that’s the sign of a relatively common/weak password. If it’s happened once? I’d be frustrated if I was trying to pick something memorable and got stuck because of that.
Here's the text: "This password has previously appeared in a data breach. Please choose a more secure alternative."
https://security.stackexchange.com/questions/8596/https-secu...
After entering my password, the app usually takes me to a second page where I am required to type out my email address. I'd much rather prefer that I get an email immediately, because the way things currently are, I won't be notified of any attempts that breach my password but not my 2FA. It provides no perceivable security benefit to me (and if someone did hijack my email account, then they know my address anyway).
If I pick the text message option, then (after confirming my number the same way as above) I get a 7-digit code. For some odd reason, I find it much more difficult to remember a 7-digit code than a 6-digit one, which seems to be standard for most other companies. I don't see any extra security benefit in a longer 2FA code, but maybe there's a valid reason for this one.
The issues above are mildly annoying on a PC. In an Xbox, however, with the onscreen keyboard, it honestly makes me want to throw my console out the window.
I think you're over focused on targeted attacks. Consider: some company gets hacked. Hackers take the credential list, try all the passwords for @outlook accounts against Microsoft using cloud VMs to avoid IP blocking. If Microsoft displayed the full email address without having the user re-type it, the attacker has now discovered the TFA email address and will try the same hacked password against that (usually Gmail) account. If Microsoft displays nothing, users with multiple emails get confused about which inbox to check. Displaying a starred out email address and asking for a re-type solves both problems. It also prevents Microsoft from having a huge SMS bill each time a big company gets hacked and the hackers try all the passwords.
The solution for Xbox is really for Xbox to use a flow designed for low input devices, like the OAuth device flow which allows you to do all the typing on your computer of cell phone, not the Xbox controller.
Sure, but why not simply show the starred out email without asking for the re-type?
I agree with the Xbox idea, that would perfectly solve the problem.
But as an individual, your passwords do matter. It makes a world of a difference to use a password manager and long, completely random passwords - such passwords are immune to all sorts of cracking attempts, and using them can often make MFA unnecessary/redundant (though using MFA always reduces your personal attack surface).
Fail2ban rules like "after 5 failed logins, ban for 30min, 10 failed logins in a day (with no succesful login) is a permaban" will curtail most non-spear phishing attacks.
"I know I used my usual password, but did it start lower or upper case? Or camel case... did I end it with a number? Did the service require a special symbol, so I added that to the end? Or to the beginning.." - banned.
The reality is that, these days, I rent $5 worth of botnet time and make {user,password} combo login attempts from thousands of residential IP addresses.
You might think your advice is a good "might as well" elementary, but generally if people want to curl your /login page from their laptop, then they are also buying $5 scripts off Hack-Forums that automate botnet cred stuffing against your service as well. And you'll need a better gameplan than fail2ban.
Don't be a PITA to your users, and you've eliminated most of the "guess what password you used" game.
If a user fails credential checks (e.g. password), track it, if their current failure rate is N, tell them they tried too many wrong credentials, come back later. Every random(1,T) seconds any failed users get their failure count reduced by one until it's zero and you stop tracking it for now.
By choosing N and T you can give users a relatively large number of "goes" to remember their password after a long period away, but not give attackers too many chances to guess a not-awful password by brute force.
For example if N is 10 and T is 7200 then a user can try ten passwords, then an average of 24 more attempts per day but exactly when they can make another attempt is random. This allows your good guys to have a fair chance against any bad guys smashing the "retry" button to try to lock them out. If the bad guys give up and go away, the user quickly returns to having ten attempts.
Lots of attacks boil down to the attacker convincing you to unknowingly divulge your password, and if that password is the only thing securing your account, you're boned no matter how strong it is.
What's to keep you from unknowingly divulging your MFA token's current generated code?
You're right that being phished/keylogged pwns a password-only account no matter how strong the password, but MFA isn't immune to phishing/keylogging/clipboard stealing either. Yes, the generated code will only give them access for 30 seconds (or whatever the algorithm's time window), but that's more than enough time for an attacker to get substantial work done.
I maintain that strong passwords in a password manager are probably good enough for security-conscious/appropriately skeptical people. For folks like that, MFA likely isn't worth the trouble - at least not quite yet.
That wouldn't completely stop someone from being able to steal the token, but it would thwart most simple keyloggers.
So if you auto-fill on a login page, it will place your username, password, and 2FA codegen into the site's authentication fields. It will not auto-suggest a login if you're not on the site it originated from - which is often enough to cause people to take a second look at the URL (which really helps thwart phishing).
Plus, it sends your authentication info to the browser via a secure connection to the 1Password browser extension, so (a) your credentials can't be keylogged, and (b) they never touch the clipboard, so they can't be stolen from there either.
But all of that is also true of non-MFA logins from 1Password. So again, I don't see the added benefit of MFA if you're already using 1Password with long random passwords.
If you try to phish it, you get credentials that are useless, because the credentials are bound to the FQDN, it will cheerfully hand over credentials for https://fakebank.example/ but they aren't the goodbank.example credentials, so it's futile for breaking into your goodbank account.
There is no keyboard entry, so nothing for a keyboard logger or clipboard thief. If you've completely taken over the user's hardware I guess all bets are off, but that's a big step up from what you're talking about.
I.e. make your passwords strong either way. It will be only worse if you won't.
It's a bad but common security error to equate password strength with matching an arbitrary schema - so yes, by that definition, so-called "strong" passwords are often useless. When a "strong" password is required, most people will unfortunately take a low-entropy word/phrase and perform single additions/substitutions until it clears the bar. Such passwords are indeed nearly worthless.
Actually it increases it. In theory it makes attacks more difficult even with the increased attack surface, but in practice, it may make it easier.
Some places let you reset a password if you have the MFA. And if the MFA was on a phone, which also has your email, which is how you'd normally reset your password, then of course it's equally vulnerable.
I wasn’t aware of that - that’s horrifying but not surprising. Well, in that case, disable/remove MFA!
On that note, if an account requires “security questions”, consider using 1Password’s password generator, but set to 4 random words separated by spaces. That can help reduce the increased attack surface from fraudulent account recovery - use words to avoid someone saying “oh it’s just a bunch of gibberish” over the phone.
What makes the "second" factor in 2FA more secure than the first? Is that it's usually a time-based generated key? Or is it that users usually use a physical device for this second key, hence removing a lot of internet-only attack vectors?
Mobile authentication apps rely on the user only typing that code into the right website—and people suck at noticing if they are on the wrong site. Right now, this is mostly only a problem with spear-phishing as most don't bother, but if 2FA becomes too popular, they'll start to adapt.
Security keys, on the other hand, get the host directly from the browser. This means they should be safe even if you fall for a phishing attack.
U2F does even better, and ensures you are authenticating to the right website, not an intermediary.
If we eliminated passwords in favor of onboard U2F chips, we'd be much better off than today, though not as amazing as U2F + passwords.
The TOTP secret is known to the authenticator, they calculate the same TOTP value as you to verify that yours is correct.
In U2F / WebAuthn the device just proves it still knows a private asymmetric key that it can use to sign messages, the authenticator learns the _public_ key, but not the private one, it can authenticate these signatures but not produce its own.
To deliver pseudonymity the device doesn't use a single public/private pair for everything but instead generates them randomly from a seed or key it knows and _this_ private value is what makes your FIDO Security Key different from my FIDO Security Key so that you can be authenticated, whilst not making it possible to fingerprint you and see where else you use these credentials.
Single Factor FIDO is a thing, Microsoft offers it. The device takes a PIN (something you know) and incorporates that into the results, so that anyone who doesn't know the PIN now can't authenticate even if they've stolen your Security Key. You need a suitable device, the Yubikey Security Keys with a "2" emblazened are suitable.
Beyond that, U2F / FIDO doesn't have a secret at all, a typical device uses symmetric ("secret key") crypto but it never actually tells anybody else that key, it's a baked-in private value for the device. This gets rid of all the attack vectors in which someone else learns your secret which you will see were many of the items in Microsoft's list.
All those arguments for why a password's strength doesn't matter because the attackers gets the exact one have one important conclusion: Don't reuse your password.
And then there are a bunch of arguments that the strength mostly doesn't matter but the password shouldn't be too weak.
So we end up with having to remember lot's of non-trivial passwords and now the conclusion should be to use a password manager and certainly not that your password "mostly doesn't matter".
What sadly mostly still doesn't matter is MFA because it is a site-specific pain to set up and use.
Just with one or two minor tweaks the analysis falls flat.
For instance, they seem to only look at mass scale script kiddie sprays, a targeted attack will likely not use the mentioned passwords. As one can come up with much better and more likely to succeed candidates.
It also entirely misses attacks that come from a more privileged position (like in Windows directly authenticating to the domain controller) where an adversary can do millions of attempts in short time because of typical monitoring gaps.
5ms?
It would take more than that to just read the 500M passwords into memory, no?
A couple of years ago I tried to bruteforce my WPA wifi handshakes and also played a bit with Hydra and I don't think I got even close to such speed.