On Sat, 19 Mar 2005 [EMAIL PROTECTED] 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/
