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: atom at smasher.org (Atom Smasher)
Subject: Re: choice-point screw-up and secure hashes

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

> Remember that the company probably needs an *invertible* function as 
> they need to be able to access the original value, so the trick of "hash 
> the SSN and see if you get the same to compare for equality" isn't 
> usable.  You can use a one-way function if the only question is "Is 
> 109-00-4368 the SSN for Customer XYZ?". If you need to be able to answer 
> "What is Customer XYZ's SSN?" you need an invertible function.  And if 
> you ever do a database JOIN based on SSN, you need the SSN.
===================

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.

but, if john smith wants to apply for credit from you, his application 
will contain his SSN and other info. this can be VERIFIED just the same 
whether it's being checked against an actual SSN or a hashed product of 
the SSN... either there's a match or there isn't!

the actual SSNs would need to be retained for several reasons, but really 
need to be kept under tighter control.

> And the sad fact is that if the company's servers are compromised 
> sufficiently to recover the hashed SSN, they're almost certainly 
> compromised sufficiently to allow the theft of the software that handles 
> the forward and reverse hashing. So considering the salt and the 
> algorithm secure if the hash has been compromised is probably a bad 
> idea..
===================

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.

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.

-- 
         ...atom

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

 	"The optimist proclaims that we live in the best of all
 	 possible worlds; and the pessimist fears this is true."
 		-- James Cabell, "The Silver Stallion"