Re: storing SSNs, CCNs, password in the DB

[Joseph Miller <joseph () tidetamerboatlifts com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Of course, the best way is not to store them.  If you do have to store them 
for logon purposes, you should hash them.  You should know, however, that the 
security of SHA1 has been under question lately due to a recent Chinese paper 
purportedly documenting the cracking of SHA1 in a relatively short amount of 
time.  (See http://www.schneier.com/bloc/archives/2005/02/sha1_broken.html).  
If you need to store them for retrieval, your webserver should be able to 
send to the database, but not retrieve the information.  Only a computer not 
on the public network should be able to retrieve the information, and access 
to that computer should be restricted.  So you will need your database to be 
on a separate computer, with restricted physical & network access to that 
computer.

- -Joseph Miller

On Sunday 27 February 2005 9:08 pm, Francesco wrote:
> It's for a web-based financial application (users accessing credit-card
> transaction information, signing in with their card number, PIN and last
> 4 of SSN) so we pretty much *have* to have that information in the DB to
> compare at logon.
>
> Francesco
>
>
>
> On Sun, 27 Feb 2005 20:28:20 -0500, "Adam Shostack" <adam () homeport org>
>
> said:
> > So, this will sound like pedantry, but it's worth starting from:  The
> > most secure way is to not store them.  Use them for what you need, and
> > then throw them away.  With increasing numbers of laws coming into
> > effect if you store these sorts of data, it may be worth business
> > process analysis to see if you can discard data early.
> >
> > If you don't have an SSN, you can't decide that it would make a good
> > password.  (You also can't report on tax issues.)
> >
> > Adam
> >
> > On Sun, Feb 27, 2005 at 02:32:12PM -0800, Francesco wrote:
> > | What is the most secure way to store SSNs, CCNs, and passwords in the
> > | DB?
> > |
> > | Is this a good general policy?
> > |
> > | 1. If you need to be able to read the data back, the encrypt/decrypt
> > | with something like TDES, storing the keys in the registry.
> > |
> > | 2. If you don't need to read the data back and you just need to
> >
> > compare,
> >
> > | then hash/salt with SHA1, storing the hash and salt in the DB.
> > |
> > | Francesco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCIyLemXZROF+EADURApRgAJwLvEYmSjjP2ZlYVhG6zkyu7k1rmACeN+m6
jS4s86qxQX3ZEOGMvu0zmwE=
=ZIFg
-----END PGP SIGNATURE-----