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

[Atom Smasher <atom@xxxxxxxxxxx>]

On Sat, 19 Mar 2005 Valdis.Kletnieks@xxxxxx wrote:

> > some companies have a legitimate need to ask that question. they should 
> > be subject to more stringent checks than our recent bad guys. FTMP, 
> > however, that question is of very little use... if you want to know the 
> > SSN of "john smith", born 1976-07-04 you're likely to come up with 
> > several matches.
>
> Exactly.  That's why the SSN ends up being the key for the database 
> rather than name/DOB.
================

which is why a hashed key is just as good as an unhashed key in most 
applications. if i look through the db for "123-45-6789", is that any 
different than looking for it's hash? in both cases i would have a unique 
identifier.


> > the solution i've described is not meant to protect servers. it's meant 
> > to protect data that people subscribe to. the fact that people 
> > subscribed to the data indicates that the servers are well protected, 
> > or at least a harder target than opening an account.
>
> Note that in general, the people who are subscribed to the data are not 
> the people who's data is being subscribed to.  It's *my* data on store 
> at <insert data warehouse>, but it's the bank or utility or car 
> dealership that's paying for access to the data, and it's yet some 
> *other* place that was the *source* of the data.
===================

complicated problem, indeed... it goes back to securing a SYSTEM, not just 
pieces of it. i'm not claiming that i've solved the whole problem, but 
i've seen part of the solution.


> > the real issue, again, is that we are talking about a SYSTEM. each 
> > component of that system has different threat models and needs to be 
> > protected in different ways. what protects the data may not help the 
> > servers... that protects the servers might not protect dead hard 
> > drives... what protects dead hard drives might not protect the 
> > network... for a group of security professionals i'm disappointed that 
> > so many people are looking for a single "magic bullet" that will just 
> > "secure" every part of a complicated system. it doesn't work like that 
> > in the real world.
>
> Notice that your "hash the SSN" defense would have done exactly *ZIP* to 
> defend against the ChoicePoint debacle that started this thread, and 
> doesn't really provide very heavy protection against a compromise of the 
> database itself.  We're not looking for a magic bullet that would secure 
> it all - but it would be nice if proposals to secure a part of it did in 
> fact add significant security to that part....
======================

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. if anyone wants to buy ACTUAL 
SSNs i think they should have a harder time buying the data. the number of 
customers that have a legitimate need to buy ACTUAL SSNs is quite limited, 
and should be able to prove themselves. make the bad guys jump through 
smaller and higher hoops, with bigger flames.


--
        ...atom

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

        "Be who you are and say what you feel, because those who
         mind don't matter and those who matter don't mind."
                -- Dr. Seuss


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