9

I have seen a couple of posts on this, but I haven't seen a definitive answer necessarily. Therefore, I thought I would try to restate the question in a new context (Department of Defense).

According to DISA's "Application Security and Development STIG, V3R2", section 3.1.24.2 Password Complexity and Maintenance, DoD enterprise software has a pretty tough guideline with passwords:

  • Passwords must be at least 15 characters long.

  • Passwords must contain a mix of upper case letters, lower case letters, numbers, and special characters.

  • When a password is changed, users must not be able to use personal information such as names, telephone numbers, account names, or dictionary words.

  • Passwords must expire after 60 days.

  • Users must not be able to reuse any of their previous 10 passwords.

  • Ensure that the application has the capability to require that new account passwords differ from the previous password by at least four characters when a password is changed.

  • Users must not be able to change passwords more than once a day, except in the case of an administrator or a privileged user. Privileged users may be required to reset a user’s forgotten passwords and the ability to change passwords more than once per day.

As stated in NullUserException's post, for the developer to actually be able to check for the last X amount of passwords (and also ensure that new passwords differ from the previous password [bullet 6]), the passwords would have to be encrypted using a reversible method, rather than hashing a password (which is a lot more unsecure, even if I am using NSA approved encryption algorithms). The proposed answer seemed to make a deal of sense, although there seemed to be some discrepancies and arguments, as seen in Dan Vinton's post.

I guess the real question here is, has anyone been able to implement all of these seemingly common password complexity constraints without actually diminishing the security of their systems?

Edit: Vulnerability APP3320.7 (bullet point 6) states "Ensure that the application has the capability to require that new account passwords differ from the previous password by at least four characters when a password is changed." That lead me to believe that I would have to run a string similarity algorithm such as Levenshtein to check similarity. I cannot do this on a hash/salt. Please let me know if I am wrong here?

Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
Logan B. Lehman
  • 4,867
  • 7
  • 32
  • 45
  • 1
    These two: "Passwords must expire after 60 days." and "Users must not be able to reuse any of their previous 10 passwords." lead to users writing down passwords. Less secure.... It's not systems that are usually the weakest point: People are.... – Mitch Wheat Feb 24 '13 at 09:54
  • 5
    Why does forbidding reusing previous passwords require you to encrypt the passwords reversible? Surely if you store the X previous hashes/salts then it is simple enough to see if the proposed new password matches any of these – Frederick Cheung Feb 24 '13 at 09:58
  • @FrederickCheung seconded. You can use hashed to check, just as login authent does. – Cris Stringfellow Feb 24 '13 at 09:58
  • @MitchWheat Either that or they use patterns that are easy to remember like `February2013`. – Gumbo Feb 24 '13 at 10:03
  • 3
    @FrederickCheung, I apologize, I believe I missed a bullet point in there. Vulnerability APP3320.7 states that "Ensure that the application has the capability to require that new account passwords differ from the previous password by at least four characters when a password is changed." That lead me to believe that I would have to run a string similarity algorithm such as Levenshtein to check similarity. I couldn't do that on a hash? Am I wrong there? – Logan B. Lehman Feb 24 '13 at 10:10

3 Answers3

12

The character distance requirement as stated is only for the (one) previous password, not the 10 previous. Assuming your password tool requires entering the current password as well as a new one, you just check against that; no need to store anything there. (Also noted on this answer to the post you mentioned.)

The requirement of not matching any of the previous 10 passwords, of course, is handled by just checking against the old hashes.

Community
  • 1
  • 1
Danica
  • 28,423
  • 6
  • 90
  • 122
  • That makes complete sense. I can't believe I didn't think of it, as it is done everywhere. Thank you for the input, and that will satisfy the requirement. If I could upvote a hundred times for filling in my dead brain at 2:30 in the morning, I would. – Logan B. Lehman Feb 24 '13 at 10:33
1

Using reversible methods to generate password-derived keys is not a secure practice and you must NOT DO IT. You must not store plain-text authentication information either. Since you will be storing keys (and perhaps salts, if you're into that kind of fetish), it is trivial to keep copies of the last 10 keys and check the newly submitted passwords against them.

Michael Foukarakis
  • 39,737
  • 6
  • 87
  • 123
-1

Requiring that new passwords differ from previous N passwords by M characters is crazy, as it implies that password history is either plaintext or reversibly encrypted, neither of which is safe.

Limiting password history to "last N" and consequently limiting the frequency of password changes to "once per day" made sense when storage space was cost-prohibitive, but makes no sense today, where storage is very cheap. A much more reasonable policy be "new passwords must not be the same as any known old passwords" and leave it at that. Ditch the "last N" and ditch the "max once daily" rule which is only there to prevent users from circumventing history.

Some password management systems support this configuration (and have supported it for many years). Example: https://hitachi-id.com/password-manager/features/password-policy-enforcement.html

user2441265
  • 514
  • 5
  • 5