When it comes to composition and length, passwords mostly don't matter(techcommunity.microsoft.com)
techcommunity.microsoft.com
When it comes to composition and length, passwords mostly don't matter
https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Your-Pa-word-doesn-t-matter/ba-p/731984
159 comments
In my opinion, Microsoft's implementation of MFA on Office 365 (at least our instance) is broken. SMS MFA is inadequate and should not be used, the SS7 network is apparently trivially hackable in some circles and text messages can be rerouted. So they want us to use MS Authenticator, great. However the 365 login screen always has the "Sign in another way" option in which I can just bypass the Authenticator app and use an SMS text. I cannot remove my mobile number from my profile to disable the option to SMS text because they are worried about me losing access to my app. I don't know if this is a limitation of Office 365 through our VAR or what, but it just seems pointless to offer an Authenticator app if there's an easy way to fall back to SMS and no way to disable SMS. If someone has my password and can reroute my text messages, a fancy shmancy Authenticator app is pointless. If this is not how it is for others with 365 I would love to know that, I hope it's not a limitation or policy put in place by our VAR.
This.
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.
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.
> No SMS text option. ... ridicolous
Agreed. My Twitter account was recently hacked thanks to T-Mobile's incompetence. [0]
[0]: https://medium.com/@simon/mobile-twitter-hacked-please-help-...
Agreed. My Twitter account was recently hacked thanks to T-Mobile's incompetence. [0]
[0]: https://medium.com/@simon/mobile-twitter-hacked-please-help-...
I'm confused... because the whole reason your twitter was able to be hacked was because the SMS option allowed it to be hacked..
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.
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.
> 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.
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.
Someone who steals your phone needs to have "physical access" to you. A random pickpocket is most likely to steal your phone and they're not interested in your phone.
Most hackers never have physical access to people. The intersection between the 2 sets - hackers and pickpockets - approaches zero.
Most hackers never have physical access to people. The intersection between the 2 sets - hackers and pickpockets - approaches zero.
You do realize that the minimum wage worker at your local phone store can setup a new phone with your number?
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.
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.
No, as other threads have pointed out, SMS is trivially hacked
If the "phone," part bothers you then just focus on the rest of what I wrote. I was making a larger point.
Everything you said agrees with what simonebrunozzi said. SMS is a bad 2FA option.
> sure its better than not having 2FA but only a little better
Only if the provider doesn't decide to be "helpful" and start allowing password resets via SMS on your 2FA number.
Only if the provider doesn't decide to be "helpful" and start allowing password resets via SMS on your 2FA number.
The problem is that twitter forces you to add a phone number, and once that phone number is added it will automatically be able for 2FA. If you don’t believe me then remove your phone number and wait. Eventually you’ll login and get a message saying your account is suspicious and you need to add a number.
I don't think SMS is real 2FA, because many site can reset password by SMS, meaning having the phone number = controlling the account = 1FA. So, it is not better but worse to have SMS "2FA" since it depends on competence of mobile provider, which may be absurdly weak at preventing social engineering.
These gaps would be obvious if services displayed all their authentication options completely in some graphical or table form. I personally would like a logic circuit diagram showing eg:
(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.
(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.
Does anyone know if there’s a way to prevent your SMS from being rerouted, or get a special protected number?
The ability to do this would not mitigate Microsoft’s responsibilities here, but at least it would allow some people to help themselves.
The ability to do this would not mitigate Microsoft’s responsibilities here, but at least it would allow some people to help themselves.
I'm not a subject matter expert, but a Google Voice number can be used to receive texts and is protected by the relatively robust security of your Google account.
If the issue is the SS7 network, that won’t help unless the originating text is also in Google Voice.
That seems pretty possible though, if SS7 is the only issue then providers of 2factor SMS auth should just have a number on each network and when a 2factor request comes in they should determine what network its being sent to and then actually send the SMS from the number they have on that network.
Unfortunately, some services won’t accept a Google Voice or any voip number.
If you had that protection, what would you do if your phone was lost/stolen and you wanted the number transferred to a new SIM card? You lose your number forever if it was impossible to transfer. If there's some way to transfer it, like showing your passport in person in the phone company's office, a hacker can pretend to be you and do that too if your account is valuable enough to be worth the risk. Ultimately, you're still trusting the phone company not to assign your number to somebody else, and that's what they're not good at.
I guess I’d like the ability to delegate the responsibility of updating the ownership of my phone number to an entity of my choosing. The phone company would only be able to update with this entity’s go-ahead. Services could specialize in this kind of work so identity verification would be a core competency, and I could pay more for better protection.
>> or get a special protected number?
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 ;-).
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 ;-).
> However the 365 login screen always has the "Sign in another way" option in which I can just bypass the Authenticator app and use an SMS text.
Not sure how that works if they (Microsoft) don’t have your phone number.
Not sure how that works if they (Microsoft) don’t have your phone number.
Can you explain this a bit further? We just switched to Office 365 and I ran into this today but I had assumed user error. So even though I have an authentication key set up there’s always the possibility that a password reset can be authenticated via my phone number?
Pretty sure you can remove sms from the 2fac process by going to:
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.
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.
When I uncheck Authentication phone I get a red error message: "Configure at least one phone so that if you lose the app you are not locked out of the account."
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
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
Yes, same thing happens to me. I’m the first account (and the only current admin) that purchased all the licenses so I wonder if that’s why. Is your account an admin or do you have any additional privileges? It makes sense that they need at least one phone number on file but there should be a way to opt out of SMS 2FA.
There are 2 other admins in our domain. We all get the same error. Through the Azure console I can disable MFA for other accounts, so even if I lost my app, one of the other 2 admins could just disable MFA until I re-enable it on another device.
Apple’s iCloud Accounts are the same now. They now require a phone number for new accounts and there is no way to remove the number.
I think the thesis of this article is rather forced. The actual claim is something like:
"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.
"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.
And also "Passwords don't matter as long as you aren't important enough or connected to a person or organization important enough to try more than the most routine password vulnerabilities"
That would be a shocking statement to make. However, I don't see anything like that in the original article. Did I miss it somewhere?
From the third paragraph:
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.
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.
Yes for example in password spray - attackers often try just < 20 passwords. If your account is high value they could try a lot more.
But the original article literally never says that. It doesn't talk about the "value" of different kinds of accounts at all (and I just reread the "Spray" section to make sure I didn't miss it).
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.
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.
There is some very bad analysis or interpretation done here.
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.
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 number one reason I don't turn on MFA has nothing to do with the effort in entering the MFA code/pressing a confirm button. The lifecycle of MFA is the problem.
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.
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.
I was blown away when I discovered that there was no way for me to export my Google Authenticator TOTP secrets from my locked Android phone, since unlocking it wipes the disk. I guess I will not make the mistake of not immediately unlocking an Android phone again.
You can save the TOTP secret on your own when setting the Authenticator. Usually you have a choice between a QR code and a text, just save the text to your separate "account recovery" database in your password manager, then set the phone with the QR. I do that with any service not offering recovery codes for their 2FA (shame on you).
Likewise, it was not fun when my phone with GA suprise died. Many services with 2FA do not provide backup codes. I switched over to Authy for this reason--they allow an encrypted backup of the TOTP secrets.
So what do you do? How did you get your account back?
I ran into a similar issue. I had 1100 dollars in an account secured by authenticator and did not save the recovery codes when I set it up. I had to jump through hoops to get it back, which is good.
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.
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.
This is why you need two options. It could be a yubikey and your phone, or a yubikey and backup codes kept in a safe, or two yubikeys, one of which might belong to a trusted relative.
Or if you're really worried about getting locked out, maybe three options.
Or if you're really worried about getting locked out, maybe three options.
And keeping a truly reliable backup is hard. Do you print out recovery codes, laminate the paper, and put them in a fire resistant home safe, or a safe deposit box?
> And keeping a truly reliable backup is hard. Do you print out recovery codes, laminate the paper, and put them in a fire resistant home safe, or a safe deposit box?
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 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.
You don't need to laminate or fireproof as long as you promptly regenerate the key if one of the two is destroyed.
Yes, those are good ideas. It's not that hard. You need somewhere to keep other important papers anyway.
[deleted]
Use an MFA app that supports exporting an encrypted backup, like Aegis.
I hope a future version of U2F will support enrolling a not-physically-present token by public key.
Not practical.
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 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.
You can actually make it work and still maintain pseudonymity. A primary key could register a backup key by generating a site-specific keypair, encrypting the site private key using the backup base public key, and then using the encrypted site private key as the key handle. The primary key would need to know the backup key's base public key, but not it's base private key, and each site would still get a unique public key and key handle.
[deleted]
Hmm. This would need a fairly substantial redesign in FIDO and might make the hardware more expensive, but in outline it sounds viable.
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.
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.
Way late reply you'll probably never see, but I'm fairly sure it's possible with the U2F protocol and existing hardware. I simplified the algo so as not to obscure the big picture, but I have actually worked out all the details and identified hardware I think would work. (I seriously considered trying to build a business around the idea and worked through the feasibility in a lot of detail. In the end I decided it was completely feasible but a crapload of work and limited marketability.)
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.
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.
>The backup/recovery options are just terrible
This is not the case if you are using a corporate controlled account
This is not the case if you are using a corporate controlled account
If you are using a password manager, use the maximum possible length – there’s no usability downside if you are already cutting and pasting.
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.
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.
The best is typing that 20 character mixed-case-plus-numbers-and-symbols password for Netflix into your TV app using an on screen keyboard and directional arrows...
I generate my passwords with:
$ 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.
$ 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.
This is a huge benefit of AppleTV and having an iOS device. When the password is prompted for on the TV, my phone buzzes and I use the LastPass vault on the phone to paste the gibberish automatically.
I'm sure there are similar schemes for other devices (Chromecast/FireTV?). But when the TV itself is "smart", I bet it's infuriating.
I'm sure there are similar schemes for other devices (Chromecast/FireTV?). But when the TV itself is "smart", I bet it's infuriating.
Chromecast doesn't have its own UI or authentication, it just uses the authentication of the device the stream was started from (being able to delegate that is a requirement for chromecast support). So it solves the same issue but in a very different way. Its a pretty clever solution but requiring all interaction with your tv to happen through another computing device can get annoying.
This is so nice!
Signing into some new tvs recently, the google account sign in experience was better than Netflix sign in, as it let you use your phone to sign in (once you’d scanned a QR code shown on screen).
1Password lets you use dictionary words separated by spaces when generating random passwords. This can be really helpful on iOS/tvOS devices -- just use speech-to-text to type them in (not to mention being easier to remember).
With the recent controversy about Amazon and Google snooping in on smart speaker recordings, people should probably avoid reading out their passwords to human listeners.
I wouldn’t use Siri or Google Assistant, since those are recorded (and I’d feel uncomfortable using a Google speech-to-text feature for that anyway).
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.
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.
How would they determine that a particular string of words was a password as opposed to any other sentence?
If it's not a coherent sentence, that would tend to be a hint. There are other explanations, admittedly.
But how is a machine supposed to be able to tell the difference? It's hard enough for humans to tell the difference between industry-specific jargon and nonsense.
Does Netflix show your full card number to you if you're logged in or is there some other justification for this level of security on it?
You need to login because accounts have different quality tiers (standard vs high definition) and different max concurrent user counts.
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.
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.
I know you need to log in, I meant to ask what necessitated such an overkill password for a mere Netflix account.
Netflix is needlessly hard on TV. Hotstar has an amazing system where it shows a 4 letter code. You open the website on your laptop or phone and enter the code. No typing in TV.
From that and lines like this one, I'm guessing the author does not use a password manager:
> 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.)
> 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.)
> So don't use a PW manager only if you're really nervous. Just use one, full stop.
And all modern browsers ship with one included, so it’s not like it’s hard to get started.
And all modern browsers ship with one included, so it’s not like it’s hard to get started.
I use more and reduce on the sites that make me type it in. Eg Netflix on smart TV. I don't want to spend time outrunning password guessing tech.
QR codes, Samsung.
QR codes, Samsung.
That’s why when I made my password generator/manager I included the option to generate translate the entropy into various forms including just alphanumeric and english words. https://slaymaker1907.github.io/password/
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.
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.
When this happens I thank my lucky stars that Mac/iOS supports iCloud copy/paste. Copy on one device and paste on the other.
[deleted]
Totally agree. VUDU app on my smart tv required me to log on every couple months, and I stopped using it eventually.
> Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.
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.)
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.)
It's hard to know who is using a password manager, but I'm sure the number is much lower, because if you're using a password manager, you are most likely smart enough to avoid phishing and some of the other attacks too (not always, but at least much more likely to be conscience about these things).
Furthermore many sites make it difficult to use a password manager because it's hard to block automated password guessers and not interfere with password managers trying to enter passwords.
My old bank used to "encrypt" your password as you typed it into the input field, on keydown it would take the character you typed and — and I'm not making this up — ROT13 it. This had the effect of making it impossible to paste anything into the input field since the script would capture your ctrl+v and replace it with the letter "i".
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.
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.
>since the script would capture your ctrl+v and replace it with the letter "i".
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.
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.
The only problem with that is that the stupid ROT13 step wouldn't be performed so the site would reject your login attempt anyway. It was one of the dumbest design decisions I've ever seen, honestly.
I'm guessing the solution would've then been to 1) disable the update event and 2) paste the ROT13'd password, either into the browser or into the input field value via the inspector.
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.
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.
My guess is if you did that and pasted "password" you would get "passworq" and then your password would be wrong according to their "encryption" method.
This reminds me of the time I was trying to explain to the Verizon store rep why I was concerned that my SIM suddenly went offline, and they told me "Oh hun, nobody steals a phone number!"
Wouldn’t the solution be to just ctrl + i your password?
Trying to block automated password guessers on the client end is a fools errand anyway.
The web developers that think like this are bad at web development, and likely security. Why would anyone trying to brute force your authentication portal care about using your UI?
This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.
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...
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...
I’m pretty sure that would be unmanageable, but love to see it tried..
Are you thinking of each character acting more like a number in a combination lock and needing to be provided to the app sequentially to be checked? I dont get how you distinguish between password managers and bots or API dictionary attacks on the same interface?
Isn't that essentially how the "I'm not a bot" captcha works though? And it seems to work pretty well.
>This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.
at that point you might as well outsource that sort of fingerprinting/behavior analysis to some service like recaptcha.
at that point you might as well outsource that sort of fingerprinting/behavior analysis to some service like recaptcha.
I mean, I suppose my idea is basically "build a recaptcha competitor". Otoh in house recaptcha is "better" because
- 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
- 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
Sounds like a great way to create a huge security flaw for your users and their passwords, or a nifty method by which your attackers can DoS your site.
KISS.
KISS.
I think this is actually done, and I wish I could remember the godforsaken website I encountered it on.
[deleted]
> Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.
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.
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.
> Otherwise, that 99% goes down dramatically because I can just steal your phone/Yubikey/whatever.
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.
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.
Eh... cars are really big. A better way of phrasing this is, "if this were true, your wallet/phone would get stolen a lot more often."
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?
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?
A wallet is useful to a thief, a yubikey is not.
There is little overlap between petty thieves and people trying to get into a particular target’s account.
There is little overlap between petty thieves and people trying to get into a particular target’s account.
> 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.
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.
It's less about "how do I steal this partícular guy's phone", and more about "how do I use this random stolen phone to access any accounts it was used with".
'Better' if you consider dramatically increasing the chances of getting locked out of your own account to be 'better'.
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.
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.
Microsoft does intend to get rid of passwords altogether:
https://techcommunity.microsoft.com/t5/Azure-Active-Director...
https://techcommunity.microsoft.com/t5/Azure-Active-Director...
This is a good article. However, in regards to credential stuffing:
> 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?
> 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?
Do you guys specifically alert the user that the password has been exposed publicly? If I got that sort of message, I would be grateful to the website rather than annoyed I couldn't use my favorite password.
We do yeah.
Here's the text: "This password has previously appeared in a data breach. Please choose a more secure alternative."
Here's the text: "This password has previously appeared in a data breach. Please choose a more secure alternative."
Not the password for you, just that password, for someone, on some site, ever.
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.
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.
Yes, I understand it was whether it's exposed anywhere, not just for this user. If it was someone else's password, I would still find it super valuable information to know I'm using something that's common enough to have been used by a stranger.
Just idly wondering... I wonder how many AJAX style sites do password checking server side and send the password to the server in plain text...
Hashing the password on the client doesn’t really gain you anything. The hash becomes the password (effectively), and you end up having to hash the hash on the server side to maintain security anyway.
https://security.stackexchange.com/questions/8596/https-secu...
https://security.stackexchange.com/questions/8596/https-secu...
I suppose it will be exchanged via HTTPS, so the risks are minimal...
What would the alternative be - sending the stored hash from the server so the comparison can be done on the client side? That doesn't sound like a great idea...
This is somewhat unrelated, but I think the Microsoft 2FA (in Outlook, Skype, Xbox, etc.) has a lot of unnecessary friction.
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.
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.
> It provides no perceivable security benefit to me (and if someone did hijack my email account, then they know my address anyway).
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.
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.
> Displaying a starred out email address and asking for a re-type solves both problems.
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.
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.
Note this is from the perspective of a security decision maker, like an IT administrator. Policy-wise, users can't be forced or trusted to create excellent passwords on their own.
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).
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).
The point of the article is that many common attacks work just as well against completely random, unique passwords as they do against weak/reused ones. If you get phished, it doesn't matter if your password is strong. If your machine has a keylogger on it, it doesn't matter if your password is strong. Etc.
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.
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.
> unknowingly divulge your password
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.
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.
WebAuthn/ U2F are, in fact, immmune to phishing, keylogging, clipboard stealing etcetera. Google reports attacks on their employees are 0% effective for systems where they were able to deploy U2F.
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.
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.
My main gripe with MFA, is that once you have 20+ services each one with a different token, it becomes tedious to sift through them to find the right one. I'd much rather have some MFA app capable of detecting where you're logging in, and a "click to authorize" option.
That wouldn't completely stop someone from being able to steal the token, but it would thwart most simple keyloggers.
That wouldn't completely stop someone from being able to steal the token, but it would thwart most simple keyloggers.
1Password has that :-)
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.
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.
The point of the article is that strong passwords are mostly useless, but unique passwords are very important. The article doesn't emphasize this, nor does it point out that this is the primary benefit of password managers. However, the very first attack they describe, which is listed as very high frequency and very easy, is credential stuffing—ie, trying credentials from a breach in other places. Unique passwords completely prevent this common attack.
I disagree with the article on that. Password strength derives from uniqueness and entropy -- nothing else. By this definition, strong passwords are very useful.
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.
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.
I don't agree that the conclusion from that is that it makes no difference whether your password is weak or strong. It does make a difference, just not for attacks that don't depend on password's length.
I.e. make your passwords strong either way. It will be only worse if you won't.
I.e. make your passwords strong either way. It will be only worse if you won't.
>using MFA always reduces your personal attack surface
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.
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.
> Some places let you reset a password if you have the MFA.
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.
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.
Rate-limiting & banning after repeat failed login attempts should be the baseline moat an IT admin or selfhosted infrastructure should have.
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.
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.
A permaban is an awful idea. A legitimate user who forgot their password can easily go through more than 10 failed attempts as they try variations of what they think their own password might be.
"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.
"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.
Hence following current NIST guidelines which do not require regular password changes, capitals, special characters or numbers in passwords: https://www.enzoic.com/surprising-new-password-guidelines-ni...
Don't be a PITA to your users, and you've eliminated most of the "guess what password you used" game.
Don't be a PITA to your users, and you've eliminated most of the "guess what password you used" game.
Or getting your account banned after someone failed trying to brute force it and not being able to access it due to changes in security policies.
Fail2ban bans an IP address or range of IPs, not specific users.
That advice is pretty antiquated.
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.
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.
Use something like random token buckets not simple rate limiting.
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.
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.
This kind of shit coming from Microsoft is fucking rich. Then why do I have to change my password constantly on outlook and get routed to at least two different types of password change servers, one with rules stupider than another? Especially when I'm trying to use a password manager with a strong, long, random password and they are preventing me from doing so with their shitty UX and their limitation on characters? They should take their own fucking advice because you know what else reduces security? The stupid bullshit I described above. Now I just use a base password (that's probably been compromised) and increase the last digit by one each time. Insecure? You betcha. But it's for work and it was work's decision to use outlook so not my problem. Microsoft should either shut the fuck up about this shit or fix their own fucking systems. Of course it doesn't matter what password you use in such a shit system (outside of a password manager generated one). And they have intentionally created a situation that makes the passwords even less secure.
Sounds like the place where you work has assigned some dumb password policies, and has a clumsy federation setup for password changes.
No, we have nothing custom set up. It's just Outlook 365. They send you to one password change page sometimes and another at other times. They both have different password policies. Microsoft is just shit as far as security is concerned. Or it could be a bug. Either way, it's garbage and it encourages not using a password manager and not using strong passwords since the length is limited. I just wish they would shut up with their fucking research into security if they won't bother to implement it themselves. Do as I say, not as I do. That's Microsoft and frankly, I'm fucking tired of their stupid bullshit.
If we start thinking passwords don't matter, we go back to single-factor authentication.
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?
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?
TOTP and U2F both perform a single authentication from a captive secret, rather than revealing a reusable secret.
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.
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.
Arguably what's inside a U2F/ FIDO token isn't a secret but a private value.
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.
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.
Quantity has a quality all of its own. For example in TOTP the secret is 160 bits. A whole swathe of those attacks vanish when "guessing" ceases to be a viable element of any strategy. Bad guys can plausibly guess a "password" but they can't guess a 160-bit value.
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.
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.
Definitely your second point, although it's worth noting that mobile authentication apps are still weak (although not as weak as just a password) to remote phishing attacks where security keys aren't.
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.
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.
The article seems to contradict itself. The table says password strength doesn't matter for brute force unless you're using an unusable password. But then in the conclusion it recommends you use a 9+ character password because that protects you from brute force.
yeah. What the table needs is a column of how to mitigate each risk. Besides MFA, there's also all the things that the very first para says aren't important, e.g. avoiding password reuse (HIBP is now a Microsoft thing)
This article is slightly inconsistent.
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.
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.
There is some very bad analysis or interpretation done here.
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.
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.
> 500M is ½ a billion, home rigs can run 100B guesses a second – so that complete list just takes 5ms to try.
5ms?
It would take more than that to just read the 500M passwords into memory, no?
5ms?
It would take more than that to just read the 500M passwords into memory, no?
Well yeah. But you, presumably, only have to do that once. After that you get 5ms per account, which seems to be the important takeaway.
But even then, 5ms seems extraordinarily fast on a home machine.
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.
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.
[deleted]
Which is why we use hardware password managers and randomly generated unique passwords for every account.
pets finalkey