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.