Entirely non-facetiously, I say "Yes, PLEASE". We're faced with the recent imposition of a rotation policy here. 🙄
--- *G. Ann Campbell* | SonarSource *Product Marketing Manager* @GAnnCampbell https://sonarsource.com On Fri, Dec 3, 2021 at 3:04 PM Shawn Hernan <sher...@microsoft.com> wrote: > Only semi-facetiously, I might say that if we all believe that needless > password rotation is a bad practice, perhaps there should be a CWE that > entitled “Obsolete Password Policies Lead to Poor Passwords” > > > > > > > > *From:* Chris Eng <c...@veracode.com> > *Sent:* Friday, December 3, 2021 10:58 > *To:* Steven M Christey <co...@mitre.org>; Seifried, Kurt < > k...@seifried.org>; CWE Research Discussion <cwe-research-list@mitre.org> > *Subject:* [EXTERNAL] RE: Time to retire CWE-262 and CWE-263 > > > > I wish we could turn this stuff off completely. The old guidance on > password aging and complexity has been deprecated for quite some time now. > > > > There are still lots of organizations out there that require their vendors > to adhere to bad security practices like password rotation. I suspect it’s > tied to various compliance regimes. So for example our AD has to have > quarterly password rotation to satisfy some big banks, even though it’s > been widely accepted to be a bad practice (long before NIST got around to > updating their guidance). Wildly frustrating. > > > > I feel like it’s our responsibility not to encourage bad practices but we > need a migration path to deprecate these completely. I would suggest very > prominent warning text with links to the NIST guidelines as well as a > planned deprecation date. I believe we have done scheduled deprecation of > other CWEs in the past, so there is some precedent. > > > > I do like the addition of “Reliance on Password Aging” as a new node. > While we’re at it “Reliance on Password Complexity Rules” or similar might > be worth adding too as complexity and aging are separate items. > > > > > > > > *From:* Steven M Christey <co...@mitre.org> > *Sent:* Friday, December 3, 2021 1:49 PM > *To:* Seifried, Kurt <k...@seifried.org>; CWE Research Discussion < > cwe-research-list@mitre.org> > *Subject:* [EXTERNAL] RE: Time to retire CWE-262 and CWE-263 > > > > *This email originated from outside of Veracode.* > > > ------------------------------ > > 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 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwe.mitre.org%2Fdata%2Fdefinitions%2F262.html&data=04%7C01%7Cshernan%40microsoft.com%7C90751f3e96094a5d66e308d9b69014c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637741552811020142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ZjNP%2FiYJaMr4MBiH3YrVQJIXFSXIFS%2FZSobyMqvsPQw%3D&reserved=0> > > Password Aging with Long Expiration - (263) > https://cwe.mitre.org/data/definitions/263.html > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwe.mitre.org%2Fdata%2Fdefinitions%2F263.html&data=04%7C01%7Cshernan%40microsoft.com%7C90751f3e96094a5d66e308d9b69014c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637741552811020142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=kataoWY5EdVgFXELrtZNuBBnW7dBu9BNUiCWR9dS1uU%3D&reserved=0> > > REFERENCES needs updating with: > > https://pages.nist.gov/800-63-3/sp800-63b.html > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpages.nist.gov%2F800-63-3%2Fsp800-63b.html&data=04%7C01%7Cshernan%40microsoft.com%7C90751f3e96094a5d66e308d9b69014c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637741552811020142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=z33JZqsp5ArIuegvbtWHg5z5uw%2BK7uY%2FKEVI8Xsstyc%3D&reserved=0> > > 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 >
