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: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Re: choice-point screw-up and secure hashes 

On Sat, 19 Mar 2005 18:18:46 EST, Atom Smasher said:

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

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

> 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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050319/17134456/attachment.bin