Best + Strongest method of encryption for databases [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

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.

Answer 1

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.

Answer 2

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.