WebApp Sec mailing list archives
RE: storing SSNs, CCNs, password in the DB
From: "McAllister, Andrew" <McAllisterA () umsystem edu>
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
Current thread:
- RE: storing SSNs, CCNs, password in the DB Jeff Robertson (Mar 01)
- <Possible follow-ups>
- RE: storing SSNs, CCNs, password in the DB McAllister, Andrew (Mar 01)
- RE: storing SSNs, CCNs, password in the DB Wall, Kevin (Mar 01)