[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200503200005.j2K05qZm015945@turing-police.cc.vt.edu>
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
Powered by blists - more mailing lists