The idea would be to run a strong password through bcrypt (with an appropriately high work factor, so that the operation takes perhaps 10ms), and then use the digest created as a symmetric key to encrypt the database record.

I would obviously NOT store the digest in the database; rather, to authenticate the user, I'd decrypt their database entry and verify that it was correct (something cheap like checking the first few bytes for a known value, for instance).

I would certainly store the work factor and the salt, as those would be needed to re-hash the provided password and generate the symmetric key.

It looks like bcrypt outputs a 186-bit hash (31 base64 chars, and I don't know why it says 184 bits here: http://stackoverflow.com/questions/5881169/storing-a-hashed-password-bcrypt-in-a-database-type-length-of-column).

Not sure if it would it be safe to pad that out and use 192-bit AES as my symmetric algorithm... or is there something insecure about that which I don't realize? Would it make sense to use a different algorithm?

Would love some feedback on whether this scheme makes sense, whether there's something better to do, and any pointers to additional reading.