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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: security at brvenik.com (Jason)
Subject: Re: choice-point screw-up and secure hashes

I don't see any disclosure in this thread but what the heck.

Valdis.Kletnieks@...edu wrote:
> On Sat, 19 Mar 2005 19:27:22 EST, Atom Smasher said:
> 
> 
>>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.

It is a trivial problem to solve.

hashkey = make_hash(known_entity, SSN);

hash_words = make_words(hash_key);

the end result might be something like this

yellow sumbarine steroids crime education lies halliburton president

for a social the values might be mothers maiden name and SSN.

make_hash(mothers_maiden_name, your_ssn);

now you have a secure method of verifying the SSN, cross referencing 
valuable data, and easily validating the results.

#1 - Solved
#2 - not needed
#3 - not needed

It has the added benefit of allowing you to capture and validate the 
important information when required without ever storing that 
information in a database.

This same method could apply to credit cards, license numbers, socials...

The merchant implementing this scheme would never have to store the 
information to prove that they were provided the proper data and that 
they were dealing with the correct entity.

> 
> 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.
> 

When the merchants enjoy lower liabilities as a result of fraud 
reduction things become a little different on the budget and political 
fronts.