| 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
| ||
|
Message-ID: <200503192238.j2JMcA95013630@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 13:34:53 EST, Atom Smasher said: > tell ya what... here's my SSN hashed with a salt: > =09e36c98b34d5ba979fb0bf0c64dc7b3a66c9ce841437d6460390e6380810f1440 > > as soon as you recover my SSN, just let me know. Tell you what - give me the salt and the hash algorithm, and it will be quick work indeed. 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. 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.. -------------- 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/ac25139c/attachment.bin
Powered by blists - more mailing lists