Good question. But as is often the case when management is asked
about these things - they say yes :)
One way to combat that is to help make clear to them how big of a
problem it would be if your social security numbers database was
compromised. Think of the PR nightmare, liability, litigation,
possibly even jail time if there's something criminal about their
improper handling of the data.
That said, if you really do need the data, and your web site/web app
needs to be able to decrypt it, then you're kinda hosed no matter
what. If your web server can decrypt it, then anyone compromising
your web server will be able to decrypt it. Even storing it
someplace PCI compliant like authorize.net won't protect you,
because your web server would have to have the login credentials to
access your PCI compliant data store, so anyone getting into your
server could get into your data store too.
Wesabe.com (personal finance tool) has an interesting privacy model.
They use a one-way hash of the user's username AND password as the
foreign key to the user's transactions. If someone were to break into
their database, they'd find a table of usernames and a table of
transactions but no way to connect them. When I've emailed them for
support, they ask me to generate a security token and send it to them
so they can temporarily access my account.
http://blog.footle.org/2007/02/22/protecting-your-users-data-with-a-privacy-wall/
I'm sure it's as comforting to them, as to me, that they've limited
their potential liability.
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
