Topic awaiting preservation: Storing sensitive data in a database

Hi All,

Was just wondering about this, i know that most systems out there don't even bother with this really.

Lets say you are storing member information for your website, they sign up enter the info, it goes over SSL to your server which writes it to your database.

If anyone gets hold of this database they will have a list of all of your users personal information, names addresses etc. The password is likely encrypted, but they have the database anyway so they don't care about the password.

Is there a good way to encrypt this information? Keeping in mind it needs to be decryptable, the website owner might need to access their details for orders, members need to edit their profiles.

So how can you keep the data safe from prying eyes, while keeping it usable.

Anyone know or have any methods they use?

Thanks

Keep The Server Safe.

If the server's compromised, all encryption that the server had keys for is broken.

And planing for someone stealing the harddisk right out of your hoster's data centre isn't usually worth the trouble.

Fair enough, I guess its a bit more concerning its shared hosting but its pretty hard to control everything.



I was thinking about using some encryption key but its only going to add more overhead and slow things down for minimal security.




Having said that i did want to make it obscured so that if someones browsing the database they dont see sensitive data, not soo much security as a slight level of privacy.

I guess for this i would just use a key of some sort ;/

In IT there's a term for this: healthy paranoia. You know that something bad will happen. You don't know who, specifically, will do it, why, how, or what they might be after. So you try and analyse what you have to try and figure out what might be targetted and what might not be, how they might get in (within reason) and from there you figure out wht precautions you can take. Remeber that there's no such thing as 100% secure. The only computer which is 100% secure is the one that is never turned on, never plugged in, and, frankly, never even built. So then you weigh up your security measures, against the detriment they make to your service. Every security measure you put in place adds another step to the process, and adds more latency to the result. You can encrypt every bit of data used in the site, but then every time it has to be used (ie: every time someone accesses the site) it has to be decrypted again. And where do you store the keys? You could have 1024 bit encryption if you wish, but if someone can get the key, you may as well be sending clear text. It's making the distinction between data that is really sensitive, and what you can replace if it's vandalised, and what doesn't really matter.

So... things like passwords should go in under a non-reversible hashing encryption, like MD5
Usernames, clear-text.
Addresses and telephone numbers... I'd consider some kind of security for them, but nothing terribly drastic
Page contents for a CMS, clear text. They're going to be called on a regular basis,and it adds too much latency ot have them encrypted.

That's just an example of it. It's really going to be up to you, in the end, to decide what's valuable, and what isn't. And remember, no amount of security takes the place of regular backups, and dumps of your databases. And there's always going to be things out of your control, like the physical security of the web servers. Unless you run them yourself, it's up to your host to secure them, and to do backups of the servers. You can regularly backup your data and download it, and you can set up cron jobs to dump your database and email it to yourself. Beyond that, there's not much you can do.


Justice 4 Pat Richard

Yeh thanks skaarj, your example sounds exactly what I might do, most of it I already do except for some very basic encryption on some personal information, that and making sure we only store personal information that we need.



Okay its all clearer now, just wanted to make sure I was on the right track and not being lazy with security!

Well most DB's have some form of encyption available like so

Maybe good for some data but it's probably going to significantly slow down some queries.



.:[ Never resist a perfect moment ]:.

On a side note - don't store anything you don't have to.
Consider removing user's shipping details once the order was fulfilled ( and perhaps the warrenty period expired), and so on.
What you don't have can't be stolen from you!

Yeh i mentioned that... its a catch 22 though - if you store those details it makes things easier for the user as they dont have to enter their shipping details everytime - which most people would find annoying.

I guess you could have it optional to store it and they can make that decision themselves.

Having said that address arent exactly sensitive information these days, and stores always need to connect their orders to shipping addresses etc for a paper trail.

Its more stuff like medical records etc that are the sensitive data