3

I'm practicing around building e-commerce asp.net applications that allows for users to register to the site and their user credentials are stored in a MySQL database. In my sample project the registration asks for the users username, password, full name, phone #, email, home address (for shipping of products purposes).

I know its good practice to store the user's password as a salted hash. But is there any other info that should be stored the same way or not? For example should the username also be stored as a salted hash or even encrypted?

I guess I'm just wondering what kinds of information is it ok to be stored in plain text in MySQL database for an asp.net web app? And which items are recommended to be stored in a salted hash? And which items should be stored using encryption?

|improve this question
  • 1
    You must first secure your database, and the OS it runs on before worrying about what's in the database. Learn the best practises for running a secure MySQL install. That topic itself is to big to be a single answer. – cgTag Dec 25 '14 at 15:36
  • 5
    Doesn't this entirely depend on the business itself? – MetaFight Dec 25 '14 at 22:01
  • 2
    @MetaFight there are requirements that the business has, there are also requirements that may come from other sources. For e-commerce, the requirements of Visa and various banks may come into play and trump business requirements. – user40980 Dec 26 '14 at 3:11
  • 1
    Note that a "salted hash" will not allow easily decryption - but I guess for most other data except the password you will need a way to access the data in decrypted form somehow. – Doc Brown Dec 26 '14 at 19:41
9

Passwords must be stored hashed always, and make sure they are never logged, for example by query loggers. Hashing is important as opposed to encryption, because it should be a one-way, nonreversible process.

Secret questions to help recover passwords are good to encrypt. As these are secret, and they themselves can reveal something about the user, it wouldn't be good if they got leaked. In addition to revealing something personal about the user, they could also help attackers to make better guesses.

Answers to secret questions should be hashed, as these could be intimate secrets. It can be a good idea to hash a sanitized form, such as lowercased and trimmed, to make it easier for users to reenter correctly.

As for other fields, it's case by case, and depends on many factors. You really need to think through each and every one of them, and evaluate in terms of sensitivity, and decide which method is prudent, or overengineering, or paranoia.

Don't forget to secure the communication channel too. For example if the system is accessible via web, make sure it's https, otherwise your hashing and encrypting makes little difference to your overall security, as everything can be eavesdropped en route between your users and your website.

UPDATE

As @MichaelT pointed out in a comment, the Payment Card Industry Data Security Standard (PCI DSS) document seems to be a comprehensive document, and well worth reading if you're serious about securing your customer data. The documents library of PCI may have other interesting items too.

|improve this answer
  • it may be worth noting that as the number of items you secure goes up, the cost of maintaining the same level of security increases as well. An attacker who retrieves a whole set of salted and hashed fields may have an easier time defeating your last-layer security than if only field was secured. – DougM Dec 26 '14 at 0:06
  • 5
    One might also want to reference the PCI DSS for various parts of securing the data (requirement 3) and communication channels (requirement 4) that required by the payment card industry (I suspect e-commerce touches n that). – user40980 Dec 26 '14 at 3:09
  • 1
    Good point re: never letting a database query logger store a plaintext password. Of course, the plaintext password should never (ever) be used in a SQL query. – Craig Dec 28 '14 at 10:03
0

I guess I'm just wondering what kinds of information is it ok to be stored in plain text in MySQL database for an asp.net web app?

What information would you be okay with being readily available to anyone, even those with malicious intent?

My email address for example is not okay to be publicly visible, even if nobody knows it's me. If you are running something like a porn site, then I probably don't want people to know that my name (or even address) is stored in your database.

If you're not showing this information to other users of the site, assume that it is private information, and your responsibility to protect.

|improve this answer
  • 1
    I can definitely understand that. But items such as email shouldn't really be hashed, I would think they should be more encrypted right? I mean the web application would need to know the email (decrypted) in certain cases to send out email notifications (if the user wants that) correct? – CD VA Programmer Dec 25 '14 at 17:33
  • @ChrisDuran - yes, that's true. – Telastyn Dec 25 '14 at 17:42
0

Every e-commerce system I've seen stores the basic user data - name, addresses, etc - unencrypted. I think that's the answer you are after. The only pieces of data that are typically encrypted are the password (hashed) and credit card info (if that's stored on site). I would probably add to that SSN's and any other sensitive financial information (bank account #'s) should be encrypted.

The reason for this is pretty simple - searching. You can't do queries such as "last_name LIKE 'SMIT%'" when the data is encrypted.

You might, though, investigate hard drive encryption if you are concerned about the physical security of the machine.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.