Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

To developers: you must not reqire a password from users

To Developers: You Must Not Reqire A Password From Users

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:

First of all – 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 leaks
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 resettings, 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 month 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 SCA, but they can start 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/

The post To developers: you must not reqire a password from users appeared on Rmag.



This post first appeared on Rmag, please read the originial post: here

Share the post

To developers: you must not reqire a password from users

×