WebApp Sec mailing list archives
Re: "data at rest"
From: Tim <tim-security () sentinelchicken org>
Date: Wed, 1 Dec 2004 22:28:40 -0500
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
Current thread:
- "data at rest" Eric Ilustrisimo (Dec 01)
- Re: "data at rest" Tim (Dec 02)