5 ms·
This sounds like such an obviously great idea that I don't know how I haven't heard it before. Can someone who understands how databases are built explain why t
by dopamean 11y ago
This sounds like such an obviously great idea that I don't know how I haven't heard it before. Can someone who understands how databases are built explain why this isn't an obviously great idea?
- nly 11y agoThe elephant in the room is what you return when you SELECT. My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should simply fail.
- DCoder 11y agoNote that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.
- dthakur 11y agoIf there are other ways to confirm whether a user exists or not (signup email check for example) -- I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.
- nly 11y ago> If there are other ways to confirm whether a user exists or not (signup email check for example) -- This would be a bug. There should be no way for someone with my e-mail address to determine if I use any particular service.
- bhauer 11y agoOne thought is that it puts the computational load of verifying user-provided passwords in your database tier, rather than in your application tier, where it exists today. Let's say that right now, you have a 200ms computation necessary to verify a bcrypt-secured password. If you have that in your application tier, you can easily scale that horizontally with more CPUs if necessary. It may be a bit more difficult to scale CPU capacity in the database tier. However, another approach would be extension of the database's client-server protocol and driver(s) such that the hash verification occurs within the application tier (as part of the driver). Or, moving further along that path, the field could be annotated in your ORM, exposing special set and verify methods. But at that point, you're very close to the current condition, where the hashing occurs within your web application framework. Or hashing could be done on the client side.
- nly 11y ago> Or hashing could be done on the client side. Only if you use a proper PAKE. A vanilla password hash is still a bearer token on the wire.