Message-ID: <775509842-1111218259-cardhu_blackberry.rim.net-21142-@engine38>
From: jasonc at science.org (Jason Coombs)
Subject: Re: choice-point screw-up and secure hashes

Good job! You've reduced by 99% the number of people who understand that the SSN is still being stored as plaintext in the database.

This should result in 100% efficacy for defense against lawsuits and other complex liability that would otherwise arise out of pure neglect and incompetency.

I suspect that CA1386 could be circumvented entirely if companies would just follow your advice. Why should anyone notify anyone else of a theft involving a bunch of ?secure hashes? ... After all, they're not SSN's any longer, and thus can't be considered personal confidential information.

Here's a general rule for everyone to follow:

obscurity = 0;
while(!obscurity) {obscurity += salt;}
...
if(security_incident && obscurity) {ignore_danger = true;}
...
if(neglect + incompetency + obscurity == best_practices) {security_business_profits += google;}


-----Original Message-----
From: Atom Smasher <atom@...sher.org>
Date: Fri, 18 Mar 2005 02:37:07 
To:recipient list not shown: ;
Subject: choice-point screw-up and secure hashes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

it seems that the recent choice-point screw-up could have been avoided if 
they read (and understood!) applied cryptography. apparently no one at 
choice-point understands what cryptographic function a secure hash can 
serve.

let's say that someone's SSN is 123-45-6789. storing that in a db might 
seem like a necessity, but what's *really* needed is a unique 
identifier... this could be achieved by hashing the SSN with a salt. using 
a salt of "19740704" (which could be read as the fourth of july, 1974):
 	SHA-256(19740704:123-45-6789)
the unique identifier becomes:
 	f7aa0fbbbe6e20a05dfe9634f30a145702b9bb0b

so, taking two known identifiers (SSN and DOB, neither of which are likely 
to change over the course of one's life) we can create a unique identifier 
that serves just as well as an SSN in nearly any db, but it's near useless 
if the data is compromised. if someone obtained a db filled with names, 
addresses, DOBs and hashed identifiers they would have a long way to go in 
obtaining anyone's SSN (and quite a long way to go in obtaining a 
significant list of SSNs). OTOH, if someone legitimately applies for a 
credit card, loan, etc, they would supply their SSN and DOB, which can be 
hashed and verified just as easily as if the db contained actual SSNs.

(as described above, the construct may be over-simplified. particularly, a 
stronger salt would be a good idea.)

of course a db with actual SSNs could also be maintained, but it could be 
kept under much tighter control (ie: NOT SOLD TO ANYONE; used only for 
internal QC/QA; used when hash algorithms need to be changed).

btw, if anyone at choice-point is reading this i'm looking for a new job.


- -- 
         ...atom

  _________________________________________
  PGP key - http://atom.smasher.org/pgp.txt
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"Man cannot pretend to he higher in ethics,
 	 spirituality, advancement, or civilization than
 	 other creatures, and at the same time live by
 	 lower standards than the vulture or hyena."
 		--  H Jay Dinshah, Out of the Jungle

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJCOoUpAAoJEAx/d+cTpVciimkH/2WpLWwCplNC/CXlfImiTdvd
d5PguTZlcixwKgFF+4M7oJ8IbscUS6UITJZ9CYLHyCL4iYOLTPgHBg1LDdk2iiI2
2yUXJPQSQAPBKrD2pwjBFtFe5WG2R5wcwWgKvhlqX4Ie38Fjni+BFFwrRw+FuVv2
3/6ZFEH8swR7g/EhhO3YTA77smdLFs9mHcbj9RHe2Nd2XyWycVJkAJtiZ/afVvkX
CdSuXmkzsjXzR+tsWQ5xZ2P1ihxX1u8eFPO1mDXYqe1T/VQ/4RIq4/n+wqnqU7/y
OJlKftWniu/aBCbSw8uZ3c7H2xT5KlUFSu5xhVYi8GxzTetb/fYcNmICL6lgeLs=
=RhR0
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists