AC22 Credential Aging review

Hi Everyone,

Threatlib has an item for AC22 Credential Aging:

{
    "SID": "AC22",
    "target": [
      "Dataflow"
    ],
    "description": "Credentials Aging",
    "details": "If no mechanism is in place for managing credentials (passwords and certificates) aging, users will have no incentive to update passwords or rotate certificates in a timely manner. Allowing password aging to occur unchecked or long certificate expiration dates can result in the possibility of diminished password integrity.",
    "Likelihood Of Attack": "Medium",
    "severity": "High",
    "prerequisites": "",
    "condition": "any(d.isCredentials for d in target.data) and target.sink.inScope and any(d.credentialsLife in (Lifetime.UNKNOWN, Lifetime.LONG, Lifetime.MANUAL, Lifetime.HARDCODED) for d in target.data)",
    "mitigations": "All passwords and other credentials should have a relatively short expiration date with a possibility to be revoked immediately under special circumstances.",
    "example": "",
    "references": "https://cwe.mitre.org/data/definitions/262.html, https://cwe.mitre.org/data/definitions/263.html, https://cwe.mitre.org/data/definitions/798.html"
  }

We have learned that continuity is a better security property than rotation. Unexpected changes, like gratuitously changing public keys changing, is bad for security because it breaks pinning controls. And requiring users to rotate their password results in users choosing weaker and weaker passwords over time just to comply with a policy based on reading tea leaves.

The details and mitigation detailed in threatlib are completely wrong nowadays. They run counter to what we have learned from real world incidents and security usability studies. Nowadays we want public keys and passwords written in stone, and only changed if there is suspicion or proof of breach or misuse.

I think AC22 should be either removed from the model or limited in scope.

Start with the AC22 definition, including its condition, details, mitigation, and CWE references in the issue. Review the Threatlib model context and determine whether AC22 should be removed or limited in scope. Done means the project has an agreed security rationale and a corrected or removed AC22 definition.