I hate password rules(schneier.com)
schneier.com
I hate password rules
https://www.schneier.com/blog/archives/2021/11/why-i-hate-password-rules.html
435 コメント
NIST best practice recommendations state:
* Require more than 8 characters
* Don't require special characters
* Don't force the user to reset their password
* Do check for compromised passwords
* Require MFA
* ...
All very sensible.
https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
* Require more than 8 characters
* Don't require special characters
* Don't force the user to reset their password
* Do check for compromised passwords
* Require MFA
* ...
All very sensible.
https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
My frustration isn't just the sites that make the password rules clear after I submit the form. The worst sites are the ones that truncate my generated password to fit their maximum password length and then don't tell me (which seems to happen in more places than it should).
Due to the nature of my job and the age of some of my coworkers, I am sometimes casually given passwords on a piece of paper. Out of a sample size of conservatively 20, I have never even once (!) seen a special character other than !. It just doesn't happen. Password rules and a requirement to change your password every X months are pure security mirage and just create frustration in people who often struggle to generate even one secure password in their entire lifetime.
(Yes I evangelize password managers around here. So far I've converted 2-3 people. They are the important people with shit people might want to steal on their computers/accounts, so I'm happy with this.)
(Yes I evangelize password managers around here. So far I've converted 2-3 people. They are the important people with shit people might want to steal on their computers/accounts, so I'm happy with this.)
Worse than password rules, are when sites disable the ability to paste in the password in the 'confirm your password' field. Forces users to reduce the 50 chars crazy password they wanted to set using their preferred password manager with a less secure version.
Here's how I do passwords - require a certain amount of entropy, and compare vs common passwords on the backend. That's it.
Here's a gif of it in action: http://files.jjcm.org/password.gif
And an example webcomponent that implements this: https://github.com/jjcm/soci-frontend/blob/master/components...
The ENTROPY_REQUIREMENT variable means you need a password that has at least 2^n possible combinations, given the character set and the length used. There's no restrictions other than that. If you want to only use lowercase letters, that's fine, as long as the length is long enough. If you include special characters, the length requirement drops.
I use a simple message to tell the user whether or not a password is acceptable, along with a radial progress bar to demonstrate success: "Not strong enough. Add complexity until the circle fills."
Here's a gif of it in action: http://files.jjcm.org/password.gif
And an example webcomponent that implements this: https://github.com/jjcm/soci-frontend/blob/master/components...
The ENTROPY_REQUIREMENT variable means you need a password that has at least 2^n possible combinations, given the character set and the length used. There's no restrictions other than that. If you want to only use lowercase letters, that's fine, as long as the length is long enough. If you include special characters, the length requirement drops.
I use a simple message to tell the user whether or not a password is acceptable, along with a radial progress bar to demonstrate success: "Not strong enough. Add complexity until the circle fills."
I had a 16 character password which I used in an PC online-banking application.
After an update the password was unable to unlock the database.
So I started creating new databases with different passwords to see what was going on, and it turned out that all passwords longer than 10 characters were failing.
So I truncated my old password to 10 characters and then it worked. No hint, no nothing in the release notes.
After an update the password was unable to unlock the database.
So I started creating new databases with different passwords to see what was going on, and it turned out that all passwords longer than 10 characters were failing.
So I truncated my old password to 10 characters and then it worked. No hint, no nothing in the release notes.
Most attacks on passwords these days are credential stuffing, not brute force.
This means that password rules REDUCE the amount of work an attacker has to do, as they can omit previously breached usernames/passwords which don't meet the password rules for the site being attacked. This means they can try more logins before getting rate-limited.
This means that password rules REDUCE the amount of work an attacker has to do, as they can omit previously breached usernames/passwords which don't meet the password rules for the site being attacked. This means they can try more logins before getting rate-limited.
I’d really love the W3C to come out with some elements that provide:
1) Communication of complexity requirements
2) Explicit password manager fill targets
3) An endpoint for a password manager to rotate passwords automatically. (and the validity period)
All of these would be backwards compatible with grandmas that write passwords on post-its and mouldering IT policies that snub NIST recommendations. Sure, webauthn is wonderful and all, but it’s a whole lot easier to ask for some simple HTML changes rather than implementing a whole API.
1) Communication of complexity requirements
2) Explicit password manager fill targets
3) An endpoint for a password manager to rotate passwords automatically. (and the validity period)
All of these would be backwards compatible with grandmas that write passwords on post-its and mouldering IT policies that snub NIST recommendations. Sure, webauthn is wonderful and all, but it’s a whole lot easier to ask for some simple HTML changes rather than implementing a whole API.
There does need to be some rules or else people would set their password to be blank or a few characters.
I would be happy with consistent password rules.
1. No password that was included in a breach a la the “haveibeenpwned” hash check system[0].
2. No password reuse.
3. A Minimum length. Something like 14-20 characters. And no maximum (or at least something set to at least 127 characters as the max allowed).
4. Reset no more than once a year.
And that’s it. All valid UTF-8 characters accepted. No requirements for special characters or not, just long well randomized passwords, or more aptly, passphrases.
Teaching everyone about password managers and diceware[1] passwords would go a long way too.
[0]:https://haveibeenpwned.com/API/v3 [1]:https://en.wikipedia.org/wiki/Diceware?wprov=sfti1
I would be happy with consistent password rules.
1. No password that was included in a breach a la the “haveibeenpwned” hash check system[0].
2. No password reuse.
3. A Minimum length. Something like 14-20 characters. And no maximum (or at least something set to at least 127 characters as the max allowed).
4. Reset no more than once a year.
And that’s it. All valid UTF-8 characters accepted. No requirements for special characters or not, just long well randomized passwords, or more aptly, passphrases.
Teaching everyone about password managers and diceware[1] passwords would go a long way too.
[0]:https://haveibeenpwned.com/API/v3 [1]:https://en.wikipedia.org/wiki/Diceware?wprov=sfti1
It also doesn't help that the complexity rules are inversely proportional to the importance of the application.
My former mortgage company's password requirements were 8 characters max, no special characters.
The app for scheduling appointments at my barber (no payment info) requires a minimum 12 character password with 2 or more special characters, 2 or more uppercase characters and 2 or more numbers.
My former mortgage company's password requirements were 8 characters max, no special characters.
The app for scheduling appointments at my barber (no payment info) requires a minimum 12 character password with 2 or more special characters, 2 or more uppercase characters and 2 or more numbers.
I hate MFA. I get the "need", but it's a) generally shittily implemented, and c) frequently manipulated/enforced not for the right reasons (notably to force you to surrender your phone number)
The worst is when some forms set rules but prevent the user from pasting a string into the duplicate field for verification. If this is meant to prevent user error in case of a typo in the first field, then it also thwarts many of us using password managers. Somehow my browser can auto-generate and enter a password, but I can’t. That’s a work-around, but it’s irksome anyway.
On another note, a more constructive metric for password security on a basic website account would be to set a complexity standard that allows multiple ways to get there. A haiku of approximately 60 plain characters, for example, should be as secure as a 30 character alphanumeric string, at least when it comes to brute forcing. It seems to me like plenty of weak passwords could be created to eke out the minimum requirements for a lot of sites, so this standard lends a false sense of security, especially when any password is recycled.
On another note, a more constructive metric for password security on a basic website account would be to set a complexity standard that allows multiple ways to get there. A haiku of approximately 60 plain characters, for example, should be as secure as a 30 character alphanumeric string, at least when it comes to brute forcing. It seems to me like plenty of weak passwords could be created to eke out the minimum requirements for a lot of sites, so this standard lends a false sense of security, especially when any password is recycled.
I had a talk with the head of security at my credit union and told him I was within this much distance of ending my relationship with them over the fact that their password rules were so tough.
I pointed out that there were some banks that had let me keep the same (securely generated) password for 15 years.
American Express tried to sell me on a deposit account to go with my card but they told me I'd need to make a new account to log in. I told them that one reason I kept my AmEx was that they didn't make me change my password every time I wanted to log in and if I had to add a second login it wasn't worth it to me.
I pointed out that there were some banks that had let me keep the same (securely generated) password for 15 years.
American Express tried to sell me on a deposit account to go with my card but they told me I'd need to make a new account to log in. I told them that one reason I kept my AmEx was that they didn't make me change my password every time I wanted to log in and if I had to add a second login it wasn't worth it to me.
Discloser: I am the co-founder (https://notesnook.com)
We used to ask our users 90% of the standard password requirements (min length 8, 1 special character, 1 digit, 1 capital etc). The result was a lot of people forgetting their password and having a really bad first impression. We were following "best practices" but the user didn't care.
In the end, we took out all the requirements except one: password must be 8 characters long. While we knew this wasn't recommended, especially for a private note taking app, it was a necessary choice because a lot of people either just modified their old passwords or used new ones which they forgot and got locked out. Good security but...if you also get locked out, what's the point? As for people who used password managers, it doesn't matter either way.
A lot of people sign up just to try out the app. Nothing serious. Nothing too critical. If they get locked out after their first usage, it's goodbye from them. I think there are a few things apps can do to improve security without annoying the user too much:
1. Show user a notice inside the app if the password is below a certain strength threshold, recommending them to change it.
2. If the password is reused or compromised, show a permanent warning either on startup or somewhere noticeable inside the app.
3. Promote use of password managers during sign up (and other places)
Ultimately, it should be up to the user to decide if they really want to change their password or risk having their account comprised.
None of these are tested though so I am not sure what the UX would be...
We used to ask our users 90% of the standard password requirements (min length 8, 1 special character, 1 digit, 1 capital etc). The result was a lot of people forgetting their password and having a really bad first impression. We were following "best practices" but the user didn't care.
In the end, we took out all the requirements except one: password must be 8 characters long. While we knew this wasn't recommended, especially for a private note taking app, it was a necessary choice because a lot of people either just modified their old passwords or used new ones which they forgot and got locked out. Good security but...if you also get locked out, what's the point? As for people who used password managers, it doesn't matter either way.
A lot of people sign up just to try out the app. Nothing serious. Nothing too critical. If they get locked out after their first usage, it's goodbye from them. I think there are a few things apps can do to improve security without annoying the user too much:
1. Show user a notice inside the app if the password is below a certain strength threshold, recommending them to change it.
2. If the password is reused or compromised, show a permanent warning either on startup or somewhere noticeable inside the app.
3. Promote use of password managers during sign up (and other places)
Ultimately, it should be up to the user to decide if they really want to change their password or risk having their account comprised.
None of these are tested though so I am not sure what the UX would be...
Since I believe a password is the user's responsibility I use the UI to inform the user what a safe password is because most people have no clue.
For example:
Choose your password: A safe password contains many different characters, for example a sentence.
For example:
Choose your password: A safe password contains many different characters, for example a sentence.
It would have been really nice if there had been an RFC or ISO standard for password composition. NIST 800-63B is probably the best advice available, but few people follow it and industry regulations (PCI) typically violate it.
1. Why don't passworded websites provide their own password generators? There's "secure" entropy generation available to JavaScript, e.g. `Crypto.getRandomValues(Uint8Array)`.
2. Shouldn't the only variable for password generation be entropy/information?
Here's a 256 bit password:
1NH8O3C3GH33FNQHM3B7VFKIQ95EMD-QLPOFPPYJ54NCFXMOB3
How could you know?
An easy way is to take the character set and convert the input string to binary. Once you reach a specified information level (say 256 bits), then the password could be considered sufficient.
https://convert.zamicol.com/?in=1NH8O3C3GH33FNQHM3B7VFKIQ95E...
3. Combined, I'd imagine a decent user experience.
4. I can't wait for public key authentication to kill passwords.
2. Shouldn't the only variable for password generation be entropy/information?
Here's a 256 bit password:
1NH8O3C3GH33FNQHM3B7VFKIQ95EMD-QLPOFPPYJ54NCFXMOB3
How could you know?
An easy way is to take the character set and convert the input string to binary. Once you reach a specified information level (say 256 bits), then the password could be considered sufficient.
https://convert.zamicol.com/?in=1NH8O3C3GH33FNQHM3B7VFKIQ95E...
3. Combined, I'd imagine a decent user experience.
4. I can't wait for public key authentication to kill passwords.
Instead of requiring people to have special password rules, we should require people to use a password manager.
Then, if you have special password rules, the manager could generate a strong password that fits into the defined rules.
Of course, getting rid of passwords entirely, is the best option (ie: using a decentralized sso solution).
Then, if you have special password rules, the manager could generate a strong password that fits into the defined rules.
Of course, getting rid of passwords entirely, is the best option (ie: using a decentralized sso solution).
I hate seeing websites that have odd restrictions like "you can use !, ?, #, and @, but not % or ^". I can't think of a reasonable reason.
I've simplified the rules I enforce because it was just getting out of hand. I enforce a reasonably long minimum length, and enforce a limit on number of repeated characters in a row (so someone can't set a password of "aaaaaaaaaaaaaaaa")
That's it.
That's it.
My fav is when it says "your password is too short" when it actually means "we didn't think anyone would try a password longer than 12 characters and your 48 character password messed up our code."
I use a password scrambler that generates a unique N-character string for every page. It's close to as much entropy as a one-time pad (technically, there is an underlying algorithm, so it could be reverse-engineered... But it'd require stealing my pass from several sites to start attacking it).
... except the sites that require a capital letter and an excalamation point. Those I sign into with "A<some random N-digits>!".
Good job, site designers. You've done nothing to improve security, but you have annoyed the hell out of me.
... except the sites that require a capital letter and an excalamation point. Those I sign into with "A<some random N-digits>!".
Good job, site designers. You've done nothing to improve security, but you have annoyed the hell out of me.
Can anyone explain to me why even new products have a maximum character limit? I frequently see 16 or 20 maximum characters. If you're hashing the password, why does it matter?
Having spent the last weekend trying to explain the arcane rules of 1Password to my mother, I can completely relate to this post. When things are overly complicated people start to work around them ... store master passwords and other codes in local files because it is a giant pain to enter them.
Corporate level password security should not be enforced on individual users who don't have IT support to keep their systems working cleanly.
Corporate level password security should not be enforced on individual users who don't have IT support to keep their systems working cleanly.
Every time I run into this, I remember meetings where a dumbass engineer would convince a clueless PM that something was necessary. It seems too specific to be thought up by a non-engineer.
I have no way of knowing this, but I do think companies with dumb password rules have poor talent.
I need to start a list of companies with dumb password rules, but I rarely create new accounts so by the time I get annoyed, I’m distracted onto something else.
I have no way of knowing this, but I do think companies with dumb password rules have poor talent.
I need to start a list of companies with dumb password rules, but I rarely create new accounts so by the time I get annoyed, I’m distracted onto something else.
Best rules I ever lived under were “We’re continuously running JTR against all users, and your password can be anything it’s unable to crack.”
I've just given up and use
The minimum character length was 50! That's a subtle way of essentially forcing you to use a password manager of some sort
I'm pretty sure this approach will eventually screw me over. I don't know how but it feels like it'll happen
$ openssl rand -base64 xx
The minimum character length was 50! That's a subtle way of essentially forcing you to use a password manager of some sort
I'm pretty sure this approach will eventually screw me over. I don't know how but it feels like it'll happen
I used to have those: 8-24 characters among which 1 uppercase/lowercase, 1 special character among a whitelist, and renew that every 2 months. At renewal, must be different from all your previous passwords and the new password must be at least 3 character different from last one. SSH keys can't be used per security policy and the same rule has been applied to the password manager.
A pain.
And yes the most annoying is that it's never the same rules, and I resort to using Keepass or worse, my browser password-remembering system (stores passwords to Google/Mozilla servers)
Is bruteforcing passwords still a thing nowadays? Once in a while I tend to forget my Wikipedia account password and after a couple of failed attempts I get shown a captcha.
On another day, I got locked out of my own account because I was trying to log in using another mobile device with another SIM in another country.
A pain.
And yes the most annoying is that it's never the same rules, and I resort to using Keepass or worse, my browser password-remembering system (stores passwords to Google/Mozilla servers)
Is bruteforcing passwords still a thing nowadays? Once in a while I tend to forget my Wikipedia account password and after a couple of failed attempts I get shown a captcha.
On another day, I got locked out of my own account because I was trying to log in using another mobile device with another SIM in another country.
I also hate when they force you to change passwords from time to time and forbid you to set one of your previous passwords. One particular offender is russian website HeadHunter [1].
I hope such people will go to very special hell after they die.
[1]: https://hh.ru
I hope such people will go to very special hell after they die.
[1]: https://hh.ru
I show up and check in with IT department. The system administrator shows me to my desk, and hands me a post it note with my password. Well pass phrase is more like it. It was something like “sliding down the tall building”.
I was quite impressed that they encouraged the use of long pass phrases instead of short cryptic passwords that are hard to remember (think “correct horse battery staple”). This place really is serious about security, I thought.
I thanked the system admin and causally said “I’ll be sure to change this to an equally secure pass phrase”.
“Oh no,” he said, “we don’t allow people to change their passwords here. You see, we need to be able to log into anyone’s computer if they go on vacation or are out of the office, so we keep an Excel worksheet with everyone’s username and password. So please don’t change your password.”
He turns and walks away, and I just sit there stunned, wondering if this was some kind of practical joke.
Sadly he was completely serious. I kept the password they gave me for the 3 months I was there, as I was asked to do, knowing that at any time someone could log in as me and do something illegal or unethical. It really did give me a bit of anxiety.