Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Security-Basics
[Top] [All Lists]

choice-point screw-up and secure hashes

Subject: choice-point screw-up and secure hashes
Date: Fri, 18 Mar 2005 02:37:07 -0500 (EST)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

it seems that the recent choice-point screw-up could have been avoided if they read (and understood!) applied cryptography. apparently no one at choice-point understands what cryptographic function a secure hash can serve.

let's say that someone's SSN is 123-45-6789. storing that in a db might seem like a necessity, but what's *really* needed is a unique identifier... this could be achieved by hashing the SSN with a salt. using a salt of "19740704" (which could be read as the fourth of july, 1974):
SHA-256(19740704:123-45-6789)
the unique identifier becomes:
f7aa0fbbbe6e20a05dfe9634f30a145702b9bb0b


so, taking two known identifiers (SSN and DOB, neither of which are likely to change over the course of one's life) we can create a unique identifier that serves just as well as an SSN in nearly any db, but it's near useless if the data is compromised. if someone obtained a db filled with names, addresses, DOBs and hashed identifiers they would have a long way to go in obtaining anyone's SSN (and quite a long way to go in obtaining a significant list of SSNs). OTOH, if someone legitimately applies for a credit card, loan, etc, they would supply their SSN and DOB, which can be hashed and verified just as easily as if the db contained actual SSNs.

(as described above, the construct may be over-simplified. particularly, a stronger salt would be a good idea.)

of course a db with actual SSNs could also be maintained, but it could be kept under much tighter control (ie: NOT SOLD TO ANYONE; used only for internal QC/QA; used when hash algorithms need to be changed).

btw, if anyone at choice-point is reading this i'm looking for a new job.


- -- ...atom


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

        "Man cannot pretend to he higher in ethics,
         spirituality, advancement, or civilization than
         other creatures, and at the same time live by
         lower standards than the vulture or hyena."
                --  H Jay Dinshah, Out of the Jungle

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJCOoUpAAoJEAx/d+cTpVciimkH/2WpLWwCplNC/CXlfImiTdvd
d5PguTZlcixwKgFF+4M7oJ8IbscUS6UITJZ9CYLHyCL4iYOLTPgHBg1LDdk2iiI2
2yUXJPQSQAPBKrD2pwjBFtFe5WG2R5wcwWgKvhlqX4Ie38Fjni+BFFwrRw+FuVv2
3/6ZFEH8swR7g/EhhO3YTA77smdLFs9mHcbj9RHe2Nd2XyWycVJkAJtiZ/afVvkX
CdSuXmkzsjXzR+tsWQ5xZ2P1ihxX1u8eFPO1mDXYqe1T/VQ/4RIq4/n+wqnqU7/y
OJlKftWniu/aBCbSw8uZ3c7H2xT5KlUFSu5xhVYi8GxzTetb/fYcNmICL6lgeLs=
=RhR0
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>
  • choice-point screw-up and secure hashes, Atom Smasher <=