ASVS icon indicating copy to clipboard operation
ASVS copied to clipboard

2.5.4 "Verify shared or default accounts are not present" - not reasonable

Open atluxity opened this issue 2 years ago • 4 comments

Hey,

I was wondering about the 2.5.4 requirement, and I consulted the references. Nothing about this is written in the NIST SP800-63b linked. The reference goes to "5.1.1.2 Memorized Secret Verifiers" and the CWE is just to the category "Configuration".

The 2.5.4 point seem to originate from this commit: https://github.com/OWASP/ASVS/commit/6298456976626a1853f296f5c892f78c3b5379ec#diff-0c2b5e7455e2813c723b067180f2b89432476e3fffc7e5d1e69b8da70e3efec4R180

And I was unable to find any discussion about its creation.

I cannot find that the existence of a share or default account like "admin" is a vulnerability AS LONG as the account is protected properly.

It is easy to say that the application is more secure without the account than with, but you can say that about any account. If this is found to be reasonable, please provide some more mention about why this requirement exists somewhere and point to an actual reference in NIST or similar framework.

atluxity avatar Oct 10 '22 13:10 atluxity

# Description L1 L2 L3 CWE NIST §
2.5.4 Verify shared or default accounts are not present (e.g. "root", "admin", or "sa"). 16 5.1.1.2 / A.3

Just first things which comes to my mind

  • Shared account - it's not possible to track to individual, who actually did what.
  • Default account - it's most likely have known credentials and it's easy target, like admin:123456 or other classic bad examples.

In both cases, I consider password as breached - I'm not the only one who knows the password for this username.

If I "read between lines" correctly, then maybe confusing part here in the requirement is the word "account" - as one may interpret it as "username" and other "username + password".

elarlang avatar Oct 10 '22 19:10 elarlang

Yeah, I get those points.

But there is a difference between "verify not present" and "do not use shared account when audit-logs are required". I know of secure systems where they call these shared account "break the glass" accounts, and is intended only to be used in emergency recovery and will have the password written down somewhere it requires two people to unlock it. Some will argue it is a "shared" account. It is certainly not a personal account. It's existence should not be seen as a vulnerability. There are ways to do this correct and there are ways to do this wrong, as with a lot of things.

There is a difference between "verify not present" and "ensure proper credentials". I think credential complexity is handled elsewhere in the requirements.

atluxity avatar Oct 10 '22 19:10 atluxity

First - I oppose the issue title - I think this requirement is reasonable. We must not allow default username+password combinations to be present.

"Break the class" or other recovery/emergency solutions do not fit to this requirement for my taste.

I think this "ensure proper credentials" is more confusing than current solution.

I'll wait feedback from others.

elarlang avatar Oct 11 '22 06:10 elarlang

Are there any other framework that includes such requirements? I was unable to find it in NIST SP800-63b and unable to map this to a CWE.

atluxity avatar Oct 11 '22 12:10 atluxity

To have a requirement in ASVS we don't need to have it anywhere else - if it makes sense, then it makes sense.

I already answered my interpretation on NIST SP 800-63B - if to translate "shared account" as breached passwords, then it's covered.

Not everything is mapped or mappable to CWE as well, things are moving forward and some things are outdated. For example - CWE-262: Not Using Password Aging is completely opposite to (v5.0) V2.1.10 Verify that the application does not require periodic credential rotation.

elarlang avatar Oct 20 '22 19:10 elarlang

In a lot of applications it is not possible to remove the default user, particularly when using another party, like ldap or AD, as source of accounts. "Not present" is the part I object to. "disabled, removed or secured" would be better. It would allow for mitigating measures, while "not present" is a requirement with little flexibility.

atluxity avatar Oct 27 '22 08:10 atluxity

"Not present" is the part I object to. "disabled, removed or secured" would be better. It would allow for mitigating measures, while "not present" is a requirement with little flexibility.

I like this. Maybe "Not Utilized" instead of "Not Present" and add the "disabled, removed or secured" qualifier.

Along this vein, should we ensure a complimentary req in 7.x that states something like "Alert on, or at the minimum log, login events for default or shared accounts."?

At least then, if a break-glass account is used, it is recorded and ideally generates an alert.

mgargiullo avatar Nov 09 '22 19:11 mgargiullo

This will be handled in #1188 and the logging point in #1577

tghosth avatar Mar 21 '23 19:03 tghosth