Hacker News Reader

Running a slow hash operation that should take a non-negligible amount of CPU on your single core per process database server isn’t a great idea.

That’s not a rag on stored procedures more generally. Just that specific use case scales poorly to a large number of operations as its inherently cpu bound.

View on HN

You can do the slow pbkdf2 hash on your webserver and use the result for your stored procedure to check the password. If the password column is only visible to the stored procedure you have used the best features of both systems.

No you can’t. To do the hash you need the per user salt before you start hashing. Which would require reading from the DB.

Then you can retrieve salt, do hash on server, and use the stored procedure to compare. More requests, but a tradeoff for security \o/

There is no reason you can‘t have a deterministic function which generates a hash for the user.

A simple sha256(lower(email)) is equally secure as a complete random salt, the only requirement on a salt is to be unique.

Reply on news.ycombinator.com