[WEB SECURITY] Encrypting Client Data

Justin Scott leviathan at darktech.org
Thu Jun 9 16:31:22 EDT 2011


Good afternoon, I have a client who works in the securities industry
and they have interest in building a web application which would store
some sensitive information about their clients.  We are looking at
using AES-256 encryption to encrypt the data within the application
and then store the encrypted data in a database.  Of course there is
concern about the encryption keys and key management.  One of the
proposed solutions is to have the end user download an encryption key
file as part of the process of establishing an account on the system.
When they log in they would then upload the encryption key file as
part of the authentication process.  The key would then be temporarily
stored in memory on the web server and used to decrypt the data coming
out of the database, or to encrypt new data before it's stored.  When
they log out or their session times out, the key data would be removed
from memory (as an aside, the app is built on a Java virtual machine
so the usual memory garbage collection methods in Java would apply,
and we can zero over the data before closing their session as well).

Other factors would be that the key stored in their file would also be
encrypted by a key encrypting key stored in our database.  The design
should allow the encrypted data for each client to remain confidential
even in the event of a compromise because it is encrypted and only the
client has the key (stored on their own computers which we would not
have access to).  In my mind this also helps to create strong
authentication because we're using two factors: something they know
(account password) and something they have (valid encryption key
file).

One issue with this design is that if a user loses their key file,
they can no longer access their data.  The client is aware of this and
finds that risk to be acceptable (it will be the user's responsibility
to keep their key file safe and available for use).

So, given this information, can you think of anything that we've
missed?  Any other risk factors we should consider?  Problems that
might come up?  Any feedback on the design we're considering would be
appreciated.  Thanks!


-Justin Scott




More information about the websecurity mailing list