Re: Time to retire CWE-262 and CWE-263

[Jason Dryhurst-Smith]

This is still a consistent battle with SecOps teams and many clients have
contradictory ideas of best practice in this area. I think clarity is
desperately needed.

+1

On Mon, 6 Dec 2021 at 14:42, Jeffrey Walton  wrote:

> On Mon, Dec 6, 2021 at 8:59 AM Kurt Seifried  wrote:
> >
> > 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.
>
> +1.
>
> Jeff
>
> --
> You received this message because you are subscribed to the Google Groups
> "Security" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security+unsubscr...@codat.io.
> To view this discussion on the web, visit
> https://groups.google.com/a/codat.io/d/msgid/security/CAH8yC8knf_nud-%3DZtDVGvCwyKSugxSc6tF86H6xkbMCvskoMjw%40mail.gmail.com
> .
>


-- 
Jason Dryhurst-Smith
Head of Engineering


301 Ink Rooms, 28 Easton Street, London WC1X 0BE

Linkedin  

Re: Time to retire CWE-262 and CWE-263

[Jeffrey Walton]

On Mon, Dec 6, 2021 at 8:59 AM Kurt Seifried  wrote:
>
> 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.

+1.

Jeff

Re: Time to retire CWE-262 and CWE-263

[Kurt Seifried]

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  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 
> *Sent:* Friday, December 3, 2021 12:57 PM
> *To:* CWE Research Discussion 
> *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

Re: Time to retire CWE-262 and CWE-263

[G. Ann Campbell]

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  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 
> *Sent:* Friday, December 3, 2021 10:58
> *To:* Steven M Christey ; Seifried, Kurt <
> k...@seifried.org>; CWE Research Discussion 
> *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 
> *Sent:* Friday, December 3, 2021 1:49 PM
> *To:* Seifried, Kurt ; 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 
> *Sent:* Friday, December 3, 2021 12:57 PM
> *To:* CWE Research Discussion 
> *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:/

Re: Time to retire CWE-262 and CWE-263

[Jeffrey Walton]

On Fri, Dec 3, 2021 at 1:17 PM Kurt Seifried  wrote:
>
>
> 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

+1. You never throw away a good secret based on [misguided] policy.

>From Security UX studies, we know each time a user is required to come
up with a new password, the new password gets weaker and weaker until
it approaches a minimum.

Here's a better reference. Peter Gutmann stated this long before NIST,
and he even cited the Security UX studies:
https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf

Jeff

RE: Time to retire CWE-262 and CWE-263

[Larry Shields]

The guidance quoted says, “SHOULD NOT”.  As defined in the doc,
The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities 
one is recommended as particularly suitable, without mentioning or excluding 
others, or that a certain course of action is preferred but not necessarily 
required, or that (in the negative form) a certain possibility or course of 
action is discouraged but not prohibited.

So, it is perfectly valid for an organization to require these controls to be 
in place for their passwords, even if discouraged.  If those are their control 
requirements, then these weaknesses describe the weakness in the system 
correctly for their control.  These still have use & function – even if you 
want to add language to clarify that control deficiency is not encouraged since 
the underlying control is discouraged.

-Larry Shields, CISSP
Chief of Information Security Services
Dept. Head R131 – MITRE InfoSec

From: Steven M Christey 
Sent: Friday, December 3, 2021 1:49 PM
To: Seifried, Kurt ; CWE Research Discussion 

Subject: RE: Time to retire CWE-262 and CWE-263

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 mailto:k...@seifried.org>>
Sent: Friday, December 3, 2021 12:57 PM
To: CWE Research Discussion 
mailto: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<mailto:k...@seifried.org>

RE: Time to retire CWE-262 and CWE-263

[Chris Eng]

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 
Sent: Friday, December 3, 2021 1:49 PM
To: Seifried, Kurt ; CWE Research Discussion 

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 mailto:k...@seifried.org>>
Sent: Friday, December 3, 2021 12:57 PM
To: CWE Research Discussion 
mailto: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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwe.mitre.org%2Fdata%2Fdefinitions%2F262.html&data=04%7C01%7Cceng%40veracode.com%7C1807b4748a064901b1ed08d9b68d8aa4%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C637741541307956933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1H7BzacBgEdFfXoHWZbx0e4yWn%2B9Bii64feJrrtEMLI%3D&reserved=0>

Password Aging with Long Expiration - (263)
https://cwe.mitre.org/data/definitions/263.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwe.mitre.org%2Fdata%2Fdefinitions%2F263.html&data=04%7C01%7Cceng%40veracode.com%7C1807b4748a064901b1ed08d9b68d8aa4%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C637741541307956933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4bTVhbnmwZh489HRsDMd7DsaQAMoa2jUZyxdVAEsa0g%3D&reserved=0>

REFERENCES needs updating with:

https://pages.nist.gov/800-63-3/sp800-63b.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpages.nist.gov%2F800-63-3%2Fsp800-63b.html&data=04%7C01%7Cceng%40veracode.com%7C1807b4748a064901b1ed08d9b68d8aa4%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C637741541308113156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=55zPRQmJacQMde0fKUHeR%2Fk07VEt5RHKD8Pnw5Oe4Do%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<mailto:k...@seifried.org>

RE: Time to retire CWE-262 and CWE-263

[Steven M Christey]

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 
Sent: Friday, December 3, 2021 12:57 PM
To: CWE Research Discussion 
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