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?
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.
Stop talking.
agree, that dude should stop talking already
How about the connection pool when there are mil of concurrent login sessions? 1-to-1 mapping doesn't sound right to me from the idea unless like the author mentioned, you're building a cooperate app that exclusively serves indoor.
and let me rephrase: you are stating from your last comment is
just leave the thing you are not mastering to the "expert"? Common, that's not how a developer should think. The starting point is wrong. Like, what could go wrong if a your db got a vulnerable issue right? or porting to another db where you had delegated part of your app to the "expert"?'The starting point is wrong' is right indeed. Never consider storing a password in the first place. The connection-resource issue in my proposal is an issue though, it can partly be solved by grouping identical authorization schemes into groups and make that happen automatically by a pooler.
And about leaving things to the expers? The public repository are littered with attempts to do something less than well understood.
An extra bonus, by the way, is that my solution allows third parties to access the data with identical authentication and, more important, authorization schemes. No application framework lock in!
Fuck off stupid shit! What should third parties do with password except store its hash to some other database???
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.