Hello everyone, welcome back to the backend master class!
In this lecture, we’re gonna learn how to securely store users’ password in the database...
For further actions, you may consider blocking this person and/or reporting abuse
No, no, do not store the password. Your database already has a solution for that. Use it and implement row-level security along the way. I like your exposé, it is clear and thorough, but the starting point is wrong. Don't ever store a password. Use other services. Your lawyer will appreciate this.
Hey Joost, I guess you didn't read the article and only look at the title. ^^
Actually, we don't store the password but only hash it using bcrypt, and only store the hashed value.
Besides, I don't know what you meant by "row-level security", or "use other services".
I did read the article. Its very thorough. And yes, you do store the password. You try to hide some of it, but many people may be able to, and will, still see a password after some trying. If you want to know more about RLS and database login roles, please click on it to Google it. There are some nice articles on it. Both mssql and postgresql have extensive support for it. Avoiding storing passwords is a by-product of it.
I think you must have misunderstood the content. There's no password stored in the DB. Only the hash-value of the password (not encrypted value). So the only way you can "see" the naked password is to brute force all possible values, hash them, then compare them with the stored hashed value.
RLS/db login roles only limit access of the company's employees, but it doesn't solve the purpose of how the web application server can authenticate users (login API). In order to authenticate user, the web app needs to check if the user's provided password (when login) matches with their actual password (when register) or not.
Storing a hash is almost similar to storing the password. Unles you can keep up with the hackers. Believe me, small private developers cannot. A hash doesn't protect you. Now of course, a bit, until the hash algorithm is proven useless in the next few years.
Login roles are not limited to inbound users. Use of login roles for everyone is a great security improvement and should be implemented a lot more often. It avoids lots of risky application solutions. Lots of critical security bugs are in applications doing the authorization in code.
How do you know whether the password user provides at login matches with his real password when he registers if you don't store anything in the DB? My point is, even if you somehow use existing technology of the DB, that technology still needs to store something about the user's password.
Or maybe you have a better explanation of how it works?
For maximum security I would suggest you use byte[] or char[] in memory rather than strings and overwrite the arrays right after you use them.
Strings are prone to linger in memory and can be recovered from a core dump or other such attacks.