Message-ID: <20050320002422.21259.qmail@smasher.org>
From: atom at smasher.org (Atom Smasher)
Subject: Re: choice-point screw-up and secure hashes

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

Powered by blists - more mailing lists