Re: Re: choice-point screw-up and secure hashes

[Atom Smasher <atom () smasher org>]

On Sat, 19 Mar 2005 Valdis.Kletnieks () 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


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/