Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
    
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

3 Answers 3

up vote 7 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
1  
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
    
@Trezoid - you're right, sorry. I'll change to BCrypt. –  Scott Whitlock May 4 '11 at 1:08

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: https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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