DEV Community

Discussion on: How to securely store passwords?

Collapse
 
jhelberg profile image
Joost Helberg

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.

Collapse
 
techschoolguru profile image
TECH SCHOOL

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".

Collapse
 
jhelberg profile image
Joost Helberg

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.

Thread Thread
 
techschoolguru profile image
TECH SCHOOL

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.

Thread Thread
 
jhelberg profile image
Joost Helberg

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.

Thread Thread
 
techschoolguru profile image
TECH SCHOOL

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?

Thread Thread
 
jhelberg profile image
Joost Helberg

Leaving authentication to an underlying product does mean it is stored somewhere, you are right about that. My experience is that no application builder understands the importance of authentication as good as the server-designers of database and other authentication providers. So, my opinion is that you'd better leave authentication to those parties and keep away from authentication as far as possible.
RLS allows you to use the user-context for determining which rows are for you and which not. The application doesn't need to bother figuring out authorization. The RLS, a static declaration and hence etter verifiable, will do that for the application.
Oauth2 is an example of using a third party authoriser, rdbms' can do it too.

Thread Thread
 
_genjudev profile image
Larson

Stop talking.

Thread Thread
 
sumtingwon profile image
sumting-won

agree, that dude should stop talking already

Collapse
 
dongocanh96 profile image
Đỗ Ngọc Anh • Edited

Fuck off stupid shit! What should third parties do with password except store its hash to some other database???