For developers: you must not require needs passwords from users
Alex P
Posted on May 3, 2024
Firstly let's glance at what we have today
Today many websites require a password
- They require "a good" password:
- minimum N letters
- at least one should be in the uppercase – and users do it with the first letter
- at least one special char – and users add the exclamation point (!) at the end of its password
- at least one number – and users add the number one (1) at the end of their password
- it is not my own opinion, just check the research of Princeton Password policies of most top websites fail to follow best practices
- And more – requirements like this are outdated now, just read the NIST 800 63b
- Users use their favorite password for all websites, but because some websites have their own requirements – users use only variations of the one password
- Websites do not notify users about possible leaked passwords
- But they can use a free API of haveibeenpwned to check possible data breaches (it's a secure API, you should not pass the users' passwords, because there is used protocol k-Anonymity – passing only the first 5 letters of SHA1-hash of the password)
- Applications do not store passwords securely, let's review the correct way:
- Firstly – use only a special algorithm for hashing a password, for example, Argon2id, scrypt, bcrypt, or PBKDF2 (my choice)
- Add salt, that stores not in the database and not in the code; because if the database leaks – application salt should not leak
- Add a UserId to the salt – if two users have the same passwords their hashes will be different
- Use a GUID as a UserId – it's difficult for guess
- The selected algorithm should have the right settings, for example, the PBKDF2 requires at least 600_000 iterations – complicates brute forcing hashes
- Read more in the Password Storage Cheat Sheet
- Also, applications do not use rate limits / throttling / invisible Recaptcha mechanisms to protect users from brute forcing by your API
- Applications with passwords must provide the possibility for password resetting, and sometimes they do that incorrectly (just read Forgot Password Cheat Sheet)
- Finally – many users do not type your website address in the address bar of their browsers, they just google your solutions by the company name
- this way is very phishable because today hackers just pay Google Ads for a concrete city to catch victims (who google) and redirect them to its phishing recourse (that could be created by gophish easily)
- many applications provide session cookies with a long expiration period, which is why a lot of users do not know what password was used (6 months ago) on your website, if they bought a new laptop, or when they lost a session
So my main points:
- Passwords are too complicated to implement a good solution, that provides a real protection
- And it's complicated for use by users (of course not for all, but for typical user of typical bookstore...)
- Many websites provide resetting passwords only by a short code to a user's email address
- That is why I have to say: many websites should forget about password usage forever, and they must start using magic links
Magic links must:
- contains a long one-time token that will be exchanged for a permanent session token
- this token works only for an IP address and a user agent, which were used for the first sign-in step – entering the user's email address
Two items, That's all!
- Now users are protected against typical phishing attacks
- If your database leaks – there won't be any passwords
- You spend less time to supporting a password workflow
- For users, who always use their favorite passwords or forget their passwords – it will be the same as a password resetting flow
PS:
- as an alternative – these websites may use sign-in/sign-up processes only by SSO, but again – they must know the best practices here too
- of course the best way – using passkeys, but I'm not sure, that all new developers (and users) are ready for it now, I'll write about it later
- for finance it's difficult to live without passwords, because they must comply to SCA, but they can start to use passkeys, and it is yet another story...
PPS: I have very good experience with good implementations and with failures on many different online solutions (sometimes as a developer, sometimes as a pentester), so please write down your concerns
Bonus if you have read that – try the password game https://neal.fun/password-game/
💖 💪 🙅 🚩
Alex P
Posted on May 3, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.