Database encryption and fields/columns that need to be decrypted

[cornflakes]

Hello,

I'm currently investigating encrypting certain database columns, such as user passwords and other sensitive data such as usernames and social security numbers.  The (java) application uses Hibernate and a MySQL database on the backend.

The use case is, username, password, and social security are stored in the database.  According to the Jasypt documentation, one should never be able to decrypt the password (the code should just compare digests).  That makes sense for passwords.  What about for other data, like usernames and social security numbers?  This is data that we'll want to encrypt in the database, but would also need to be retrieved.  Where would/should the encryption key be stored (so if someone hacks through the system, they cannot decrypt this information from the database)?

Jasypt seems to handle this, but I wanted to confirm with the following, more specific questions:

1. In the application code (business logic), what will this code be working with?  More specifically, as mentioned in the article below for encrypting user passwords, it says "you should not even have a way to get to read/know/see your users' passwords, no matter if you are the system administrator".  I understand that for passwords, but for other data, like social security numbers or usernames, we'll want to make sure that the data stored in the database is encrypted, but that we can obtain the original data (username and social security number).  How does Jasypt handle this, or more importantly, how should this be handled in the application (using Jasypt)?

http://jasypt.org/howtoencryptuserpasswords.html

2. If we use Jasypt to encrypt the database column for the user password using a one way digest method, there is no way of someone gaining access to the original password (as you explained in that article).  

With regards to the usernames and passwords, these too can be encrypted in the database, but since we need to be able decrypt this information, wouldn't an encryption key need to be stored somewhere (like in the application layer)?  Where should this encryption key be stored, so if someone were to hack through the system, they couldn't decrypt these fields?  Or maybe there is a better way to do this?

Thanks in advance (and sorry for what could be obvious).

[cornflakes ()]

I looked at the following article which shows how Jasypt does database encryption with Hibernate:
http://jasypt.org/hibernate3.html

Under the section "Providing the encryptor to Hibernate", there are two options": Using Spring and Without Spring.  In the examples Using Spring the password for the encryptor is stored in the spring bean definition.  Is that not a security hole?  Where should it be stored, as an environmental variable and then read in?  Security-wise, is that sufficient?

In the example Without Spring, there is no password at all.  Should there be?  Where should it be stored (to comply with security standards)?

To summarize, the use case I have is:

1. encrypt user passwords
2. encrypt other sensitive data, like social security numbers, names, and bank account numbers.

With regards to 2, the reason for encrypting this data ((like social security numbers, and bank account numbers) is if someone runs off with the box, he/she could not do anything with the data.  This data, however would still need to be decrypted by the application so it can be used (or presented to the user).  Where should this encryption/decryption key be stored?  How does this work with Jasypt (the guide states that encrypted attributes/properties cannot be used as part of projection queries (SUM, MAX, ..) as this is done on the database before decryption by hibernate, and cannot also be part of an ORDER BY clause).  I guess they can be used with the WHERE clause, as long as a fixed salt generator is used?

Thanks!