←back to thread

430 points tambourine_man | 2 comments | | HN request time: 0.002s | source
Show context
mr_mitm ◴[] No.41879391[source]
I'm glad someone is thinking about UX and ergonomics when it comes to passwords. Most people I interact with have by now realized that generating passwords is a good idea. But if you are already generating the password, please do not include special characters. I regularly use different keyboard layouts (sometimes it is not even clear which layout is active, like in the vSphere web console), and the fact that passwords are often not shown on the screen when typing them makes for terrible UX and causes frustration.

The usual advice about character classes is only for casual users who don't know what makes a secure password. Entropy is the deciding factor: Ten random lower case letters is much more secure than "Summer2024!", which satisfies most password rules and has more characters.

Personally I stick to lower case letters for things like my Netflix password or Wifi key, because typing with a TV remote can be a huge pain. To keep a similar entropy, just increase the length by one or two characters.

replies(10): >>41879469 #>>41879535 #>>41879556 #>>41879734 #>>41879735 #>>41880345 #>>41880499 #>>41881423 #>>41881471 #>>41883418 #
Terretta ◴[] No.41880345[source]
> The usual advice about character classes is only for casual users who don't know what makes a secure password.

Arguably, it was to make early rainbow tables less feasible.

> if you are already generating the password, please do not include special characters.

This would make your generator useless on most sites. Since it's not the generator making up this rule, it's the web site's password "complexity" requirements.

I do agree password strength tests should just measure bits of entropy and allow whatever's typed that's high enough.

replies(5): >>41880400 #>>41880402 #>>41880520 #>>41881041 #>>41885295 #
vlovich123 ◴[] No.41880402[source]
I don’t believe it’s possible to estimate the amount of entropy in a password - it’s too short so then you have to evaluate it against a dictionary. That’s why things are moving to passkeys but NIST recommendations thankfully have finally been updated to stop recommending weird password rules.
replies(3): >>41880629 #>>41880895 #>>41881912 #
1. ziddoap ◴[] No.41880629[source]
>NIST recommendations thankfully have finally been updated

Finally? It's almost been a decade since since special publication 800-63B was published recommending against silly things like composition rules and arbitrary password rotations.

replies(1): >>41882508 #
2. vlovich123 ◴[] No.41882508[source]
The NIST guidelines have changed "should not" to "shall not" for 800-63B this year. The reason this is important is that the very first NIST guidelines recommended rotations and composition rules. Even after 800-63B was first published, people continued to use the earlier guidelines under the assumption it was better and the "should" wording let them keep doing it. The shall change should force a broader change which is why it's significant. Another notable change this year is the banning of security questions:

> Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and > Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. > Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

> Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.