DoD Password Complexity: Users cannot reuse any of their previous X passwords

Question

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?

Solution 1

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.

Solution 2

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.

Comments

[Logan B. Lehman]

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.