I learned this technique when I worked on the blue team of a cyber security firm.
It’s not about sending your passwords in clear text to your RDBMS. You’d still use bcrypt like you normally would but instead of querying the password table directly you’d have that prewritten as a stored procedure. That way you can have different permissions for the password table.
Some frameworks and/or other managed solutions might already be doing this but it’s worth mentioning anyway since people are talking about hand rolling their own auth.
I don’t know why I added the part about offloading encryption though. That doesn’t make sense. I guess that will teach me talking security before my first coffee of the day
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.
Comments
I learned this technique when I worked on the blue team of a cyber security firm.
It’s not about sending your passwords in clear text to your RDBMS. You’d still use bcrypt like you normally would but instead of querying the password table directly you’d have that prewritten as a stored procedure. That way you can have different permissions for the password table.
Some frameworks and/or other managed solutions might already be doing this but it’s worth mentioning anyway since people are talking about hand rolling their own auth.
I don’t know why I added the part about offloading encryption though. That doesn’t make sense. I guess that will teach me talking security before my first coffee of the day
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.