A customer of mine recently asked me to try a penetration test on his website,
and I found a nice SQL Injection vulnerability. Using that vuln I was able to
wander round his DB at will, viewing customer information, user logins,
passwords, the lot. He asked me to make some recommendations, of which the
first was to close the vulnerability. But it also got me thinking about
encrypting sensitive information in the DB.
If another SQL Injection vulnerability turns up (which it might, given the
state of the website code), the data in the DB will be vulnerable to anyone
who looks, which might be someone less friendly next time. My gut reaction is
to say "encrypt anything sensitive" but a little thought makes that seem like
an over reaction. After all, aren't modern database systems supposed to be
secure in their own right?
It seems silly to tell him to encrypt everything, including customer names and
addresses, etc. - I've never heard of DB admin recommending such action - and
it'll have an impact on performance. So where do I draw the line? Encrypt
everything on the basis that it adds a layer of security? Encrypt nothing on
the basis that there shouldn't be any way of accessing the sensitive stuff so
the extra security isn't necessary? Or encrypt a few things, just in case?
What do people recommend?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
