considering two approaches. the first is storing both a one-way
encryption/hash on the data to enable searching and a masked version
of the original data for display (i.e. 12XXXXXX34). this way we never
store the original data in the db. the drawback is that we can't
recover the original data, which might be needed for other processing.
This is pretty good, if you can get away with it (the app doesn't need
it again), but there are also pitfalls in it. For instance, what if I
wanted to store a users' record in the DB, which contained their SSN.
Later on, as some sort of security measure, I want them to tell me their
SSN so I can verify. So, I hash the SSN, and call it good. Wrong. If
my DB is stolen, (and the attacker figures out how I am hashing SSNs),
then it wouldn't take long to crack right through that hashing
mechanism, esp if I don't salt. You see, there isn't a lot of entropy
in an SSN, esp if I were to say... also store DOB with the record, in
cleartext. There are very specific rules about what prefix numbers get
used for what states in the US, and ways to correlate DOB with probable
SSNs. A few thousand guesses is all it would take in some cases to
crack the hash. So, if the data you are hashing is predictable, then you
aren't gaining much. CC numbers aren't much better, since the last 4
digits you'll probably have to store for display, and the first four are
closely correlated with card type and bank. (harder than SSN though)
I am not saying using one-way hashes are bad. They are definately
better than storing with symmetric key, and keeping that key on the web
server, but you might consider something like an HMAC.
In your explorations of what to use for data at rest, keep in mind that
if the data you are storing is going to be used by the application, at
all frequently, then chances are that low-level crypto won't do anything
against a remote breakin. If an attacker compromises a web app because
they took over the whole server, then they have the same rights as your
web app. Most of the techniques people try to sell you only provide
physical security. You know, when random people make it by security and
steal your mainframe... stuff like that.
(see: http://www.theregister.co.uk/2003/09/05/the_case_of_the_two/)
Good luck,
tim
