Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. 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

Given the Sony data breach and other events recently, is there any actual laws or regulation regarding how to store passwords? I think there are with credit cards, you're not allowed to store the 3 digit key or something.

Is it illegal to actually store plaintext passwords without warning the user? Or it there a level of encryption that has to be used?

Are there any standard guidelines that anyone can point me to?

share|improve this question

closed as off-topic by Snowman, Scant Roger, Bart van Ingen Schenau, Ixrec, GlenH7 Jan 6 at 18:57

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to find or recommend tools, libraries, programming languages, resources (including books, blogs, tutorials, and examples), or projects to undertake are off-topic on Programmers as they attract opinionated answers that won't have lasting value to others. You may be able to get help in The Whiteboard, our chat room." – Snowman, Scant Roger, Bart van Ingen Schenau, Ixrec, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

This will almost certainly vary by region. That said, there's no excuse for plain-text passwords - they are too easy to steal, and if confidential data is accessed with a password found in plain-text, data protection legislation will almost certainly bite you, due to lack of due-diligence. – Phil Lello May 4 '11 at 1:36
up vote 8 down vote accepted

Regarding the storage of payment card data, what you're looking for seems to be called the Payment Card Industry Data Security Standards or PCI DSS.

According to Wikipedia:

The standard applies to all organisations that hold, process, or exchange cardholder information from any card branded with the logo of one of the card brands.

Unfortunately I don't know of any regulations for storing user passwords. Here is what I've heard is good practice, but I know it's probably not enforced:

  1. Use a library - don't try to write good encryption/hashing code yourself
  2. Don't store the password, store a hash (bcrypt seems to be good as of this date)
  3. Generate a unique "salt" for each user, and concatenate the password with the salt before hashing. This reduces the risk of rainbow table attacks.
  4. Don't keep passwords in memory any longer than you have to. Use framework tools like SecureString in .NET to help manage the security of plain text passwords while in memory.
  5. Don't display passwords on the screen (both to avoid over-the-shoulder and EMI-based attacks)
  6. Don't allow passwords to pass across public networks in plain text (the FTP and Telnet protocols are infamous for this). Use SSL/SSH/HTTPS to secure your connection first.
  7. Require passwords with some minimum complexity. Don't limit the complexity!
share|improve this answer
I disagree with #7. Often you can type a ton of gibberish as your password and it comes up as weak because you don't have a number. I don't care if it doesn't have a number, asjdklfjqruiowezjf is not going to be caught by a brute-force attack. (rainbow attacks don't matter if you have unique salts) – alternative May 4 '11 at 0:41
@mathepic - where did I say you must require a number? I just said "require passwords with some minimum complexity". You can check minimum length, check it against known dictionary words, etc. – Scott Whitlock May 4 '11 at 0:44
@Scott Whitlock And what I mean is those usually get in the way. Especially known dictionary words when you have a word inside your gibberish by accident, but its not really recognizable (akjqwehellorjkau) – alternative May 4 '11 at 0:45
I disagree with parts of 2 (sha-1 is way WAY too fast for passwords), but other then that, these are things that should just be common sense but unfortunately aren't. – Trezoid May 4 '11 at 1:01
2 & 3 should part be part of 1 (bcrypt for example generates a hash and salts for you) – Brendan Long May 4 '11 at 1:10

For something like a social network, or web-mail, or Stack Exchange - no, there are no legal security standards whatsoever. You could store user passwords on pieces of paper stuck to the outside of your corporate headquarters, and you wouldn't be breaking any laws.

(I'm talking just about the USA - it might be different in other places.)

share|improve this answer
Ha, well, you might not be breaking any laws by doing that, but I'm pretty sure you'd be opening yourself up to a rather big class action lawsuit. – Scott Whitlock May 4 '11 at 11:54

The only regulation that I am aware of (and it's only a Credit Card brand regulation for merchants and software providers) is that you must not store the password in databases or files in unencrypted form. For instance, our Software recently underwent PA-DSS 2.0 certification and we encrypted the passwords using SHA-1 encryption with a unique salt for each password hash. Also, you are required to encrypt passwords during transmission (e.g. from Client to Server). In the US at least, the Government has stayed out of major software mandates such as this unless it affects Government assets such as computers or software used by the military.

As far as storing the key, there are special rules for that too. 3 digit key? Too small. To read more about how you can adhere to the PA-DSS 2.0 standard, read here:

share|improve this answer
The National Institute of Standards and Technology recommended five years ago that "Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical". It's not a mandate obviously, but if they recommend against it for their own agencies, I'd avoid it myself. – Carson63000 May 4 '11 at 3:18

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