I think it's not an OBSOLETE issue, it's an active change in policy due to further research and knowledge.
A great parallel is "3DES is good. USE 3DES!" which was a GREAT policy in 1998. It has since been retired and its use has been banned by NIST after 2023 ( https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA ). Why is the password aging issue any different? In fact, it's pretty much identical, NIST said this was a good idea, further research/technology movement happened and we learned it was a bad idea. So bad in fact it should probably be banned. Also, the ONE positive aspect of rotating passwords, which is an attacker gets a password, uses it, and this effectively locks them out, means your controls are so weak that: 1) you can't detect an attacker in the system and you basically have to hope they get locked out after 30/60/90/whatever days because of password rotation 2) your users are choosing bad passwords and/or exposing them somehow (phishing?) which means your access controls are basically doomed to fail at some point anyways and password rotation effectively covers this up and prevents real movement forwards. On Fri, Dec 3, 2021 at 11:48 AM Steven M Christey <co...@mitre.org> wrote: > Kurt, > > > > For a while, I’ve been wondering what to do about these. We have a Status > value of “Obsolete” which might be useful, or we could outright deprecate > them. At the absolute minimum, actively discouraging the practice makes > sense. > > > > However, we still need to account for the CWE use cases in which > real-world code – for whatever reason – is still using password aging. We > have to allow for multiple software development models and contexts for > product users. Some kind of CWE entry still needs to be available for > people to point out the mistake. > > > > So perhaps a new entry like “Reliance on Password Aging” could be created, > and these two could be deprecated. > > > > I’d love to hear broader discussion from others on this list. Is it time > to deprecate these two entries outright? Are there any legitimate cases > where password aging still makes sense (even from a practical standpoint)? > Or maybe keep CWE-263 since it’s a followon weakness that occurs because of > that bad choice? > > > > Thanks, > > Steve > > > > > > *From:* Kurt Seifried <k...@seifried.org> > *Sent:* Friday, December 3, 2021 12:57 PM > *To:* CWE Research Discussion <cwe-research-list@mitre.org> > *Subject:* Time to retire CWE-262 and CWE-263 > > > > > Not Using Password Aging - (262) > https://cwe.mitre.org/data/definitions/262.html > > Password Aging with Long Expiration - (263) > https://cwe.mitre.org/data/definitions/263.html > > REFERENCES needs updating with: > > https://pages.nist.gov/800-63-3/sp800-63b.html > > 5.1.1.2 Memorized Secret Verifiers > > Verifiers SHOULD NOT impose other composition rules (e.g., requiring > mixtures of different character types or prohibiting consecutively repeated > characters) for memorized secrets. Verifiers SHOULD NOT require memorized > secrets to be changed arbitrarily (e.g., periodically). However, verifiers > SHALL force a change if there is evidence of compromise of the > authenticator. > > And ideally, we should rewrite BOTH of these CWE's to state "these are > retired/wrong" > > > > -- > > Kurt Seifried (He/Him) > k...@seifried.org > -- Kurt Seifried (He/Him) k...@seifried.org
