Why most password requirements are silly. Also, here's our flavor(medium.com)
medium.com
Why most password requirements are silly. Also, here's our flavor
https://medium.com/@tony.infisical/password-requirements-are-still-confusing-in-2023-also-heres-our-flavor-44ce03a3255c
6 comments
Yes
And do not forget rule 0, the rule above all : prohibit password's usage as much as possible. Use private keys or SAML or whatever.
And do not forget rule 0, the rule above all : prohibit password's usage as much as possible. Use private keys or SAML or whatever.
Bravo! Now can we get rid of those dumb password entry fields that show you a typed character for 2 seconds, then convert it to a dot? With no option to "Show password"?
That's a practice that was maybe good in the days of large monitors with a large viewing angle, and large fonts. It might have been possible to shoulder surf back in the day, but now we have small screens with narrow fields of view that display tiny fonts, and are held less than a foot from your face. It's not possible to shoulder surf these days.
That's a practice that was maybe good in the days of large monitors with a large viewing angle, and large fonts. It might have been possible to shoulder surf back in the day, but now we have small screens with narrow fields of view that display tiny fonts, and are held less than a foot from your face. It's not possible to shoulder surf these days.
I'd wager shoulder surfing was never that likely, but it is much less likely today and much harder. However, high def recording is much more prevalent these days. The one thing I like that some password forms have started doing is obscure the username. Usually the first time you enter it, its plausible to grab, but subsequent entries, only grabbing the password, if it is at all feasible, isn't as useful without the username.
I'm sincerely glad I haven't seen login forms that obscure the user ID. Blind user ID entry, followed by 10+ characy,high entropy password, also blind, on a tiny keyboard with no tactile feedback. Don't know about you, but my fingertip can cover 2 phone keyboard virtual keys, and touch corners of 3 or 4 at once.
Logging in is already excruciating. That would make logins secure by making them impossible.
Logging in is already excruciating. That would make logins secure by making them impossible.
What bugs me is the inappropriateness of most password requirements. At my work, the most onerous password requirements are on the timesheet app. Really? If you want to fill in my timesheet for me every week, then be my guest.
On the other hand, my bank has a online user no, and a passcode to access it online, plus to do anything unusual (like set up a new payee) I need further authentication from a one time code generated on a dongle using my debit card. All very sensible.
On the other hand, my bank has a online user no, and a passcode to access it online, plus to do anything unusual (like set up a new payee) I need further authentication from a one time code generated on a dongle using my debit card. All very sensible.
1. The maximum password length should be high; perhaps at least 127 characters, possibly more. The minimum password length should not be less than 5 or greater than 8.
2. Passwords should be allowed to contain any non-null bytes (0x01 to 0xFF). Do not check if they are valid characters or check for bad words or anything like that; any sequence of bytes should be acceptable, and it should not "normalize" them. Passwords must be case-sensitive.
3. The hashes of passwords should be stored rather than the password by themself. Passwords might also each have their own salt, or use other data in the hash such as the user name, or both.
4. You should never be required to change your password after any amount of time, but should be allowed to change it whenever you want to do.
5. Do not use "security questions" such as mother's maiden name etc.
6. When creating or changing the password, ask for the password twice.
7. Depending on the user interface, you may wish to check for common mistakes such as entering data that is probably meant to be somewhere else (such as an email address or user name), but you should accept it anyways if the user insists that it is correct.
8. In the case of multiple incorrect logins in a short interval, you should prevent further logins. Depending on the specific system, there may be some exceptions, in order to prevent someone from stopping legitimate users from logging in.
9. Other methods of authentication may be possible for some systems e.g. HMAC, public/private keys, X.509 certificates, etc.
10. When designing the user interfaces, tell the renderer that it is a password field (in a HTML form, you would use <input type="password">), and the client software may be able to be configured to show or hide the password according to your preferences (as well as what font to use).