[Full-disclosure] Re: choice-point screw-up and secure hashes
atom at smasher.org
Sun Mar 20 00:27:22 GMT 2005
On Sat, 19 Mar 2005 Valdis.Kletnieks at vt.edu 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
>> 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.
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 is hosted and sponsored by Secunia.