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

| Subject: | RE: storing SSNs, CCNs, password in the DB |
|---|---|
| Date: | Tue, 1 Mar 2005 09:23:23 -0600 |
-----Original Message----- From: Andrew van der Stock [mailto:vanderaj@greebo.net] Francesco said:It's for a web-based financial application (users accessingcredit-cardtransaction information, signing in with their card number,PIN and last4 of SSN) so we pretty much *have* to have that informationin the DB tocompare at logon.Unless you're the employer of these people, proving welfare services, or require the SSN for mandated government reporting you must NOT collect or use the SSN for authentication purposes as you can't repurpose the collection from its primary purpose. The SSN is also available in many semi-public ways, so it's not a good authenticator and is officially frowned upon.
There is no regulation or law that prevents a private organization from requesting, requiring or using a person's SSN (if provided by it's owner). Some companies like banks will claim that they require SSN's because of money laundering laws, but I have yet to find the actual law that does require it. Federal, state, and local government agencies are prohibited from collecting or using SSN's unless specifically authorized by law, but you'll find that there are MANY exceptions and it still happens quite often regardless of the law. The law that prohibits this is the "1974 Privacy Act" it does not affect the private sector. That said, collecting and using SSN's by private organizations is a BAD idea. Smart customers don't like it and dumb ones will think it was you who gave out their info when their identity is stolen.
http://www.ssa.gov/pubs/10064.html
There are better resources. Try googling for "1974 Privacy Act".
The card number is a poor account identifier as attackers can loop through your institution's BIN numbers and DoS lockout your application trivially.
Yes. I've seen it happen. A 4 digit pin works great on an ATM machine, but NOT on the net.
The CCV (the three digit validator) is ephemeral data only. You must not use this in a persistent way unless you are the issuing institution, and even then you should take appropriate steps to protect the confidentiality of this data.
Visa and Mastercard prohibit the storage of CCV (or CVV2) information after a credit card authorization stage unless as you say you are the issuing institution. Storage of the CCV number after authorization whether on paper, disk, memory, encrypted, whatever is punishable by a $50,000 fine from Visa/MC on the first offense.
Try again. :) Andrew
Indeed. As others have posted, your best bet is to store a hash of the information or truncate the information. For example if you use the last four digits of the SSN, then store only the last four digits. If you really are going to encrypt credit card data, then you MUST follow Visa/Mastercard guidelines and use split key dual control with a minimum of 128bit for symmetric or 1024bits for asymmetric encryption. Split key dual control means that a key must be split up and given to at least two people. From Visa's guidelines you CANNOT simply give half the key to one person and half to another, you must split at least 4 ways and give piece 1 and 3 to one person and 2 and 4 to the other. Read up, there's been lots of discussion on this. Andy
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Preventing direct URL access in a J2EE environment, Kevin Conaway |
|---|---|
| Next by Date: | Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection], Jeff Williams |
| Previous by Thread: | RE: storing SSNs, CCNs, password in the DB, Jeff Robertson |
| Next by Thread: | RE: storing SSNs, CCNs, password in the DB, Wall, Kevin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |