Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am building a hosted (SaaS) web application that stores PII like name, email address, and employer of the user. As of right now, I don't intend to ever store credit card numbers or bank account numbers or social security #'s, etc.

I would like to be able to claim that my service follows "industry standard" security practices, but I am a bit unclear what this means today. For example, is a password hashed by SHA-1 or MD5 that is properly salted still considered industry standard and acceptable?

In general, what guidelines do people follow to determine "industry standard" practices from all angles so 1) you are adequately protected from malicious activities and 2) won't get hammered in court if you ever get sued over a data leak.

Also, how does this change if you store more sensitive PII like a social security #?

share|improve this question

closed as too broad by Scott Pack, NULLZ, Iszi, AviD Nov 26 '13 at 8:11

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Storing passwords hashed with MD5 or SHA1 is not best practice. Best practice is to hash passwords using bcrypt, scrypt, or PBKDF2 (see also this question) or to use a third-party authentication provider, like OpenID or (shudder) Facebook Connect.

I second @david6's recommendation that OWASP is a good source of information for industry standards for web security.

I also recommend that you read the following two introductions to secure web software development:

They provide information that I think every web developer needs to know. I think it is fair to say that best practice is for your developers to have some familiarity with security issues and how to write secure code. For more reading, see my answer about this.

You might also consider testing the security of your website, either using automated pentesting tools, or by hiring a penetration tester or penetration testing service. This is probably unnecessary if your site does not collect or store any sensitive information. But if it stores sensitive information, then this is probably a good idea.

share|improve this answer

If you are not using credit cards, or similar information, you (thankfully) do not need to consider PCI-DSS compliance.

For general 'industry standards' based security for web hosting, look to OWASP:

share|improve this answer

I work in government. We follow the FBI's Criminal Justice Information Systems Policy. You can find it here.

share|improve this answer

You need to look at industry and country specific regulations, some important examples are:


share|improve this answer

If all you are storing is name, email, and employer, then things do get much easier for you. But OWASP/SANS/WASC is only one half of the picture. You need to look at the way you store the data, not only how it is accessed. Storage issues look at the database, the server, and the controls internal to your organization that control who has access to that data.

As for SSN, look at:

On the other hand, what you could do to certify yourself is get 3rd party verification of the security of your site by hiring a professional website tester. That way, instead of saying that you comply to a standard (which don't fully exist yet), you can say that you passed an external security test. Independent testers can be found inexpensively, geared towards small sites on tight budgets.

share|improve this answer

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