9

The DISA Application Developer STIG specifies:

Group ID (Vulid): V-69565

Rule ID: SV-84187r1_rule

Rule Version (STIG-ID): APSC-DV-001730

Rule Title: The application must require the change of at least 8 of the total number of characters when passwords are changed.

The Check Content isn't any less vague:

When prompted to provide the password, attempt to change less than 8 characters of the total number of characters in the password.

If less than 8 characters of the password are changed, this is a finding.

My team and I are having a hard time determining the official interpretation of this rule. Does index count? Does adding 8 new characters onto your original password count as changing 8?

We ended up determining the difference using the Levenshtein Distance algrorithm, but fear that our success may be determined by the subjective interpretation of someone else who might perform IA tests/scans on our application in the future.

Is there some "official" technical definition of a "change of at least 8 characters"?

Improve this question
5
  • 1
    Can you clarify what you mean by the comment "does index count"?
    – PwdRsch
    Feb 3, 2017 at 17:03
  • 1
    @PwdRsch if indexes 'count' (matter), then the string "abcd" would be considered completely different from the string "cdba" because the character at index 0 is not the same in both strings, and so on. Without considering index, you could consider the second string in that example to be a 0-character change from the first string.
    – Austin Hill
    Feb 3, 2017 at 20:23
  • 4
    For what it's worth, I'm thinking that your solution using the Levensthein distance is very thoughtful and an excellent interpretation of the rule. The people making the rule probably didn't think very far at all. I'd assume they were thinking of the simplest case, e.g. compare a string byte by byte and count how many characters changed, and they didn't think of the fact that "12345678" and "23456781" would satisfy that rule while completely missing the point of it. If they had been thinking of cases such as this one, they'd have defined the rule more carefully.
    – Out of Band
    Feb 4, 2017 at 12:53
  • 1
    @Pascal I suppose at the very least we have good ammunition for defending our choice if we run into others who's interpretations differ from ours. Thanks!
    – Austin Hill
    Feb 4, 2017 at 16:59
  • this is old, but another way around this is to use access cards, which is preferred. "Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication"
    – captainmish
    Jun 28 at 8:15

2 Answers 2

Reset to default
1

Without any trickery, the simplest way to do this is when a password change is requested, require the previous password as well. After verification of the previous password against the current hash, you now have the plain text of both old and new in memory which you can then discard after comparison. If everything checks out, save the new hash.

Improve this answer
0

The safest interpretation would be to make sure there are 8 entirely unique new characters that were not included in the previous password at any index.

I can see one example from Unified Compliance here using the difok parameter of pam_cracklib in particular.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .