[Full-disclosure] Re: choice-point screw-up and secure hashes

[Atom Smasher]

On Sat, 19 Mar 2005 Valdis.Kletnieks at vt.edu wrote:

>> the way i see it, some people bought personal info from choicepoint. if 
>> that info contained hashed SSNs it would be just as valuable to a 
>> LEGITIMATE user for verification purposes.
>
> Explain why. Remember that I'm sitting down at the bank applying for a 
> loan, and *I* have no idea what my SSN hashes to, and the bank has a 
> vested interest in getting back a report they can easily verify is The 
> Right One - this means that either the report back from ChoicePoint 
> needs to contain a cleartext SSN that the loan officer can verify, or 
> the bank needs to be able to hash my SSN and compare (ever 
> eyeball-checked the MD5sum of a file you downloaded?  Now imagine a 
> non-techie doing that all day - it's significantly harder than using 
> eyeball compares for 2 sets of (3,2,4) digit numbers...)
>
> And it has to have one of the 3 following characteristics: 1) It has to 
> work over a fax machine, because that's what the competing companies 
> have as the entry level technology. 2) It has to provide *such* 
> additional benefit *to the subscriber* to make them pay for an 
> essentially one-use piece of hardware.  The fax machine they can use for 
> all their fax needs, a specialized hardware for connecting to your 
> database is probably not going to be a win. 3) You have to be willing to 
> pay for the hardware for your subscribers.
>
> Remember - the people who are going to end up paying for the security 
> aren't the people who care about the security - which will tend to limit 
> your security budget.
==================

you walk into the bank and fill out the paperwork for a loan. you fill in 
all of the blanks, including SSN. this form is taken to be verified, 
either in the next room or after being faxed off-site (over an unencrypted 
fax line?).

in any case, someone will type your SSN, DOB and maybe 1-2 other 
identifiers into a terminal. that application will perform a one way 
function on your SSN and look up the result in the db. it prints out the 
info (including the actual SSN), which can be compared to your 
application. if you provide an invalid SSN it won't be found, same as 
before. if you supply a fraudulent SSN, it may be found, same as before.

advantage to the bank: their db (which can be accessed by a LOT of 
employees) does not contain SSNs. this limits their headache in the event 
that the db is accessed without authorization.

in this implementation, no one has to know what a hash is... the UI is 
just the same as before. it "just works (tm)" the same as before. all 
hashes are invisible to the user.


-- 
         ...atom

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

 	"The National Government will regard it as its first
 	 and foremost duty to revive in the nation the spirit
 	 of unity and cooperation. It will preserve and
 	 defend those basic principles on which our nation
 	 has been built. It regards Christianity as the
 	 foundation of our national morality, and the family
 	 as the basis of national life."
 		-- Adolph Hitler
 		Proclamation to the German nation at Berlin,
 		February 1, 1933