6

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?

Michael K
  • 15,539
  • 9
  • 61
  • 93
RoboShop
  • 2,770
  • 6
  • 29
  • 38
  • 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 04 '11 at 01:36

3 Answers3

9

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!
Scott Whitlock
  • 21,874
  • 5
  • 60
  • 88
  • 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 04 '11 at 00: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 04 '11 at 00: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 04 '11 at 00: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 04 '11 at 01:01
  • @Trezoid - you're right, sorry. I'll change to BCrypt. – Scott Whitlock May 04 '11 at 01:08
  • @Scott: PA-DSS requires numbers in the password and SHA-1 is acceptable per PCI DSS. – Engineer2021 May 04 '11 at 01:09
  • 1
    2 & 3 should part be part of 1 (bcrypt for example generates a hash and salts for you) – Brendan Long May 04 '11 at 01:10
  • I wish I had known about bcrypt when we implemented SHA1 for user passwords at my previous Company. I know it now. The auditor said SHA1 was good enough. Go figure. – Engineer2021 May 04 '11 at 01:14
  • It seems most people outside the security industry don't actually understand why SHA1 isn't good enough. They think "if it hashes, that's all I need", forgetting the whole fact that the advantages of a fast hash are equally it's downfall... – Trezoid May 04 '11 at 01:18
  • @Trezoid: The scary part is my company paid $50,000 for a security assessor to audit our software and SHA1 was listed as OK. In fact, PCI DSS just says you have to hash the password but does not say SHA1 is not OK and to use something like bcrypt. My suspicion is that it is not one requirement that is more important than another but rather defense in depth (centralized logging requirement, auditing of system objects and application files, digital signatures on installations prior to transmitting to customers, policies and procedures).. but then I digress. – Engineer2021 May 04 '11 at 01:25
  • .. and the auditor is in the security industry. – Engineer2021 May 04 '11 at 01:28
  • @OAOD: Makes you wonder how they got any kind of accreditation. I think the legislation is left open for future improvements, rather then to suggest a good current minimum. The big problem is that what may be best of class now (bcrypt) may become horribly broken with future technologies (quantum computing?) – Trezoid May 04 '11 at 01:34
  • I think SHA1 *can* be good enough if you iteratively apply it thousands of times - if something is doing that already, it might be OK. It's obviously still not as good as using something designed for the job such as bcrypt. Use bcrypt if you have the option. – rjmunro Dec 03 '15 at 12:45
3

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

Mike Baranczak
  • 2,614
  • 16
  • 16
  • 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 04 '11 at 11:54
0

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

Engineer2021
  • 3,238
  • 5
  • 28
  • 32
  • The National Institute of Standards and Technology [recommended five years ago](http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html) 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 04 '11 at 03:18