2

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
4
  • 3
    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.
    – Reactgular
    Dec 25, 2014 at 15:36
  • 6
    Doesn't this entirely depend on the business itself?
    – MetaFight
    Dec 25, 2014 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, 2014 at 3:11
  • 2
    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, 2014 at 19:41

5 Answers 5

Reset to default
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
3
  • 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, 2014 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, 2014 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 Tullis
    Dec 28, 2014 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
2
  • 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?
    – CAMD_3441
    Dec 25, 2014 at 17:33
  • @ChrisDuran - yes, that's true.
    – Telastyn
    Dec 25, 2014 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
0

According to me password,Email Address and Id must be stored in encrypted way.It is good practice for secure your website.And If you have payment module then credit card number and cvv must be stored in encrypted manner.

Improve this answer
0

Hashed data means there is no way to get the original back. So any field where you actually need to use the cleartext for any purpose (sending and email, shipping a product), you can't use hashing.

This means hashing is only really appropriate for passwords.

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.