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

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

The 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 = '[email protected]' 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.

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

That's true currently of any HTTP-level logs

Yes, it is, but that doesn't excuse doing it here.

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

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