6

I am storing Paswords and Personal Data in a database. What is the strongest method for encrypting these values for protection.

Also, what is the best method for encryption for Credit Card info in a database? Or should I use something else to store Credit Card Info, not a mysql database??

Thanks.

H Bellamy
  • 22,405
  • 23
  • 76
  • 114
  • 7
    Never store credit card info. – Shakti Singh Nov 19 '11 at 16:39
  • 3
    @ShaktiSingh so how do companies like Amazon and the Like store them? – H Bellamy Nov 19 '11 at 16:40
  • 2
    read : http://stackoverflow.com/questions/3002189/best-practices-to-store-creditcard-information-into-database – Book Of Zeus Nov 19 '11 at 16:40
  • 4
    Or http://stackoverflow.com/questions/2240705/online-credit-card-storage. You are much, much better off letting a third party firm do the credit card handling for you, because you need to follow the PCI DSS standards. For the passwords, it's best to do a one-way hash. For personal data, MySQL has AES built-in, but if you want longer than 128-bit keys you might have to recompile the code. – Scott A Nov 19 '11 at 16:48
  • 1
    @HBellamy: You have to take care of many-many things while storing credit card info and very much risk involved in it. – Shakti Singh Nov 19 '11 at 16:59

2 Answers2

11

I think storing anything in SQL is fine, just encrypt it first. If you need to identify the data in some way (such as with a unique key for the DB entry) create a randomly generate string, or a secure hash, and store that along side of your encrypted data.

It is probably best to stick with something that is tried and tested. Since it is a DB (presumably for a billing system) it would be good to have fast retrieval. So stay away from asymmetric encryption -- which you should only use to encrypt the symmetric keys if you need to share them with someone.

Some particular strength (say 256 bits) of AES should be fine. I would be happy to know my personal details we secured in this way.

In terms of storing users passwords, it is common practice to generate a salt ( a random string ) and then hash the users password combined with this salt using a secure hash algorithm (RIPEMD, SHA1, MD5).

This prevents a pre-computed dictionary cracker from recovering the passwods since it needs to handle all the random salts as well.

Do not encrypt passwords, only hash them. There is no need to be able to recover the password in cleartext, it only makes your system vulnerable via this one master key. Do not encrypt users data with keys that users can choose, it will make the data unrecoverable in the event of key loss. Provide common ways for users to recover access to their account in the event they lose their passwords.

If you really need to hide usernames, perhaps you should be asking yourself about the data architecture you are using. In general, personal data and especially billing data should not be stored in plain sight, it should be only accessible by trusted parties. These trusted parties will have need to view the content of user names and info, hence encryption is probably unnecessary.

If you are transmitting user info on the open internet, encrypt it.

If you are concerned about the security of user info on your DB server, perhaps consider working with a cloud or data hosting provider who can provide you with some additional physical security for your servers.

Encryption is only part of a robust security policy. Focus especially on the human element of setting up a secure environment in which to conduct your biz. Hand out access to sensitive resources on a need to know basis. Make sure that you arrange for backups or some means of data recovery should all keys be lost.

Cris Stringfellow
  • 3,714
  • 26
  • 48
  • 1
    +1 Nice thorough answer – Mark Hall Nov 19 '11 at 17:18
  • [nope](http://stackoverflow.com/users/1283048/nope)'s comment: "'So stay away from asymmetric encryption -- which you should only use to encrypt the symmetric keys if you need to share them with someone.' - That doesnt make any sense - why would someone encrypt KEYS except for TLS? Of course asymmetric encryption has its (many) uses - in fact, one should avoid symmetric encryption-methods as they are vulnerable by design IF the transport-stream is unencrypted; knowing the public key with asymmetric encryption does not grant decryption-capabilities." – Peter O. Oct 28 '12 at 20:04
  • @PeterO. It actually does make sense... the slow, asymmetric public key encryption method is used to encrypt the exchange of the symmetric keys. The fast, symmetric key encryption is in turn used to encrypt the data stream. – spamsink Apr 06 '13 at 05:39
1

Note that encryption isn't the only thing you need to worry about when storing credit card data. There's also strict auditing requirements and a host of other concerns (see the PCI website if you're unfamiliar).

While you can probably manage to get PCI compliance, doing this if you're not really familiar with the necessary security measures can leave you open to huge liabilities. If your system is breached or you are found to be non-compliant, you face serious fines.

Check out payment providers such as Authorize.net for alternative solutions. Specifically, their Customer Information Manager product is worth looking into as they will store secure data such as credit card info on their servers for you.

Michael Mior
  • 28,107
  • 9
  • 89
  • 113