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/
Top comments (21)
In defense of passwords
I disagree about the password vs magic links.
About password implementations -> you are right that they are a little complicated, BUT
I agree with your concerns
And you are free to develop options for technical users – they can find the switcher...
But as the technical user I'll request not passwords or magic links (or oauth) – the most wanted feature for me is WebAuthN now 😉
Webauth is not ready yet
Webauth in my current understanding does not really work as an open protocol across multiple vendors -> you have to completely buy-in into a propriety vendor solution like Microsoft, Google or Apple. Usage of a hardware dongle/usb/Yubikey can completely locks you out moment it gets lost. Especially if your are on a vacation in another country with your laptop/phone stolen -> imagine getting locked out of all your accounts and losing access to all of your money and communication methods, how much fun is that?
I think this blog post has a good summary there the author of an open source library and editing author of the standard - suggests that its better to be just using passwords instead.
fy.blackhats.net.au/blog/2024-04-2...
Depending on Apple only for it to completely wipe all your Keychains does not seem like a reliable or secure solution to me.
Or do you mean an different webauth than passkeys and dongles?
That are you thoughts on the article?
heard reasoning from the Security Now podcast, this is the article they discussed.
I think that passkeys give me a little more than one password, because in almost all resources where passkeys are supported, I can add many fallback options (other Passkeys) and store one of them in the password manager;
More than a year of experience in use, including implementation on our website - so far there are no problems with them;
I don't have an apple account to compare
But I agree that in the case without a backup keys it's dangerous situation
Complex password requirements is the conspiracy of password management software manufacturers against humanity… 🧐
Very interesting take, at first I had no real bias toward this subject, and even I was against using magic links but the more I think about it, the more it makes sense because a user will only log to your application through the internet, since the API will validate its authenticity, so we can asume he as internet connectivity.
If the user has internet connectivity, it is way easier and safer to authenticate the latter using a magic link. The only downside I see is that this adds another layer of reliability since a mail provider that is down means the whole authentication down. But at the same time, mail providers employ so much effort and money to make their service reliable, you have more chance of going down than them.
Plus, it means no more passwords to mess with, and I've always advocated security before performance or cost so it is an added benefit for the user: a friendlier solution toward authentication, and a safer experience.
I've already started to see some application or two use this to allow authentication and I think I'll start advocating for that and use it for my own apps.
Thank you for this very interesting article and take regarding this topic!
I really hope that someday we will forget our passwords and never return to them.
neal.fun: stuck on chess board.
You mean like a password manager?? 🤔
I meant information would be anonymized, the opposite of confidential. Finally, data will be reused rather than duplicated. We'll save quite a bit of storage space. Distant future or in next decade, who knows.
Very interesting article, I honestly did not know all this stuff about passwords
Great article, but if I may, please fix the typo in your article title except if it's international
Thanks, I hope now it's better
Or just say me, what is wrong
I'm not good in English
I would like to recommend you using LanguageTool to check your article.
You can also add an extension to your browser.
languagetool.org
Here is the result for your article, so except the "require", you are pretty good.
For information, I'm French, LanguageTool helped me to improve my English by showing me the errors I was doing in the context.
I should write an article about it, BTW
Nice, I'll try it too 👍
Actually I use the grammarly.com/
I switched out Grammaly 3 years ago. I like languagetool can be used with a local language tool server, so nothing is sent to the cloud.
I definitely need to write an article about it…
requireneeds auI disagree about the "Magic links must save user agent".
As a developer/technical user I use multiple browsers and multiple email accounts.
Example use case, so then I try to
Yes, if you accept the risk and agree with the IP matching – why not!
Anyway – you should think about the phishing cases, and prevent them
Password Requirements -> a long length is enough. Writing sentences as passwords is the best choice (after using a password manager of course).
I believe a low amount of users use a password managers and really thinking about their passwords strength 🙃
That is why the Princeton Research recommends to add a password strengs meter on UI and then... every user wants to create a good password, but after they will use the Frogot password button... Round 🤪
Some comments may only be visible to logged-in visitors. Sign in to view all comments.