| I can't really use bcrypt like I normally would, since bcrypt normally* concatenates the cost and salt into a single string with the hash that I store in my database:
https://en.wikipedia.org/wiki/Bcrypt I believe I can split out the cost and salt. That would let me: 1. SELECT the user's salt and cost from a table that is accessible with my web app credentials. 2. Run bcrypt on the user-provided password with the selected salt and cost within my webapp. 3. Ask my stored procedure if my resulting hash matches the hash in the database, even though I cannot SELECT the hash directly with my web app credentials. Am I understanding this correctly? I imagine it would have been easier pre-bcrypt, when generating salts was less abstracted away from the developer. I can't think of a reason this wouldn't work, and it adds a layer of security if implemented properly. But I say that hesitantly, as I would all things crypto, particularly since I wouldn't consider it common practice and I'm not sure if I'm overlooking something. I'm pretty sure I'd need to hack on bcrypt-ruby more than comfortable to actually implement. * I say normally because that's what the wiki says and how bcrypt-ruby behaves, but I haven't done wider research. |