[Xk]

No.

If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access.

However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?

[cHalgan]

If you are storing something in database which needs to be decrypted (i.e., you are storing credentials to access some other system) it is common sense not to have that key in the database.

The key should be provided to your application on startup.

Or sometimes, the key can be in the wallet and that wallet can open only during startup of the application: application should prompt admin to enter password needed to open the wallet.

At least that how I design my systems... Maybe I'm wrong...

[theBobMcCormick]

Prompt the admin for a password? So there's no way to do an unattended reboot of the application? That doesn't sound very practical.

[cHalgan]

Hey... If you want to be secure that what you need to do. The keys must not be easily accessible.

Anyway application which need to be secure are not the one you also would like to be restarted automatically or unattended: automatically restart can in many cases just make situation worse (i.e., data corruption)

You can always pay big bucks and use Oracle Database with Transparent Data Encryption: in that case, you need to enter password to open the wallet only on startup of a database.

[ceejayoz]

We're required to have our sensitive data on an encrypted volume by a client (a major financial firm). Sometimes, calling the 24/7 techs to enter a passphrase is a perfectly appropriate solution, especially if you have enough capacity to let a server or two wait until the morning.