2.10.1 Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys

[Sjord]

2.10.1:

Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.

What does this mean? How should you authenticate to other services? My application currently authenticates to the database server using username and password, and uses API keys to access several API's. Is that in violation of this requirement?

What is the proper way to do manage intra-service secrets? Can we rephrase this to a positive requirement instead of a negative requirement?

What does it mean for a secret to rely on credentials? When are credentials unchanging?

What was the original purpose of this requirement?

See also https://github.com/OWASP/ASVS/issues/763.

[jmanico]

I think the general suggestion here is that

OAuth2 tokens + mTLS > mTLS alone > API Keys > Passwords for API access

Or in short, API keys in general are weak API access methods.

But for sure this requirement as-is is over-reaching.

[Sjord]

I attempted to retrieve the history of this requirement, but it doesn't provide much more information:

• 0e0ca929649c414ed535855499ff4c4560ed200b Verify that intra-service secrets do not rely on unchanging passwords, such as API keys or shared accounts with privileged access.
• c0f9c295ea57ecfba848cfbdca850034825117f1 Integration secrets SHOULD NOT rely on unchanging memorized secrets, such as API keys or shared privileged accounts. If memorized secrets are required, the credential should not be a default account, and stored with sufficient protection to prevent offline recovery attacks, including local system access.
• 81a5b36119d2345fe14fff890abb44f13c3a11b7 Integration memorized secrets SHOULD NOT rely on unchanging memorized secrets, such as API keys or shared privileged accounts. If memorized secrets are required, the credential should not be a default account, and stored with sufficient protection to prevent offline recovery attacks, including local system access.

[Sjord]

I propose to delete this requirement.

[wet-certitude]

@jmanico I would consider the private key of an mTLS connection "unchanging" as well. I see that the private key, unlike a password/token is not transmitted - at least that is one interpretation, but one that after much thought, I could not figure out based the current stipulation alone.

Since it's been over a year since this was reported and no one was able to figure out what exactly this means, no one is going to miss this stipulation if we simply remove it?

[settantasette]

I do not think deleting this requirement is the right way to go, rather I would re-phrase it to bring in some clarity. I understand @jmanico's point, but at the moment the way control point is presented is very confusing. Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access. Does it mean that secrets should not use passwords etc. whatsoever ? Or if for example passwords are rotated daily then its acceptable ? Since its not "unchanging credential" anymore. Then question comes what is acceptable rate of rotation of credentials ?

[tghosth]

@set-reminder 5 weeks @tghosth to look at it

[octo-reminder[bot]]

⏰ Reminder Monday, January 16, 2023 12:00 AM (GMT+01:00)

@tghosth to look at it

[tghosth]

I agree this requirement is unclear and it is not clear what it was based on to begin with.

Given the topic of this section, I would suggest simplifying to:

Verify that service authentication uses either mTLS or a credential which is unique to that service and rotatable. Where supported, temporary session tokens should be generated and used instead of sending the credential on each connection.

Thoughts/opinions?

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to look at it

[Sjord]

Verify that service authentication uses either ...

I think we should have a requirement that requires authentication between services.

either mTLS or a credential

I think other methods of authentication are also acceptable. Although "a credential" can of course mean a certificate or a JWT or anything.

which is unique to that service and rotatable

This should perhaps be moved to a more general requirement. All the secrets that the application uses itself should be unique, rotatable, non-default (2.10.2), etc.

Where supported

This is a pretty big escape hatch, if the developing party is developing both services that communicate with each other. They can choose to not support this.

temporary session tokens should be generated and used instead of sending the credential on each connection.

I don't understand this. Why would this be better?

[sseelmann]

Doesn't the current 2.10.1 contradict with 2.10.4 which defines how such "internal secrets" (if that's meant by "intra-service secrets") should be managed:

2.10.4	[GRAMMAR] Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage should resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.		✓	✓	798

PS: and isn't 2.10.4 overlapping with 6.4.1? But that would be a separate issue to discuss.

6.4.1	[MODIFIED] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets such as service account or 3rd party application credentials. (C8)		✓	✓	798

[tghosth]

Adding some additional context:

History:

#	Description	L1	L2	L3	CWE	NIST §
2.10.1	Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.		✓	✓	287
2.10.1	Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.		OS assisted	HSM	287	5.1.1.1
2.10.1	Verify that intra-service secrets do not rely on unchanging passwords, such as API keys or shared accounts with privileged access.		OS assisted	HSM	287	5.1.1.1
2.10.1	Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.		OS assisted	HSM	287	5.1.1.1
2.11.1	Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.	Software	OS assisted	HSM	5.1.1.1
2.11.1	Integration secrets SHOULD NOT rely on unchanging passwords, such as API keys or shared privileged accounts.	Software	OS assisted	HSM	5.1.1.1
2.11.1	Integration secrets SHOULD NOT rely on unchanging passwords, such as API keys or shared privileged accounts. If passwords are required, the credential should not be a default account and stored with sufficient protection to prevent offline recovery attacks, including local system access.	Software	OS assisted	HSM	5.1.1.1
2.21	Integration secrets SHOULD NOT rely on unchanging memorized secrets, such as API keys or shared privileged accounts. If memorized secrets are required, the credential should not be a default account, and stored with sufficient protection to prevent offline recovery attacks, including local system access.	Software	OS assisted	HSM	5.1.1.1
2.21	Integration memorized secrets SHOULD NOT rely on unchanging memorized secrets, such as API keys or shared privileged accounts. If memorized secrets are required, the credential should not be a default account, and stored with sufficient protection to prevent offline recovery attacks, including local system access.	Software	OS assisted	HSM	4.0	5.1.1.1

From Andrew's deck:

[tghosth]

PS: and isn't 2.10.4 overlapping with 6.4.1? But that would be a separate issue to discuss.

6.4.1	[MODIFIED] Verify that a secrets management solution such as a key vault is used to securely create, store, control access > to and destroy secrets such as service account or 3rd party application credentials. (C8)		✓	✓	798

@sseelmann please can you open a separate issue to discuss if one does not already exist

[tghosth]

Verify that service authentication uses either ...

I think we should have a requirement that requires authentication between services.

You mean an extra requirement "before" this one that just requires intro-service authentication?

either mTLS or a credential

I think other methods of authentication are also acceptable. Although "a credential" can of course mean a certificate or a JWT or anything.

What other methods of authentication? "Credential" is pretty flexible wording...

which is unique to that service and rotatable

This should perhaps be moved to a more general requirement. All the secrets that the application uses itself should be unique, rotatable, non-default (2.10.2), etc.

Yeah, I hear that... It's like a catch-all requirement

Where supported

This is a pretty big escape hatch, if the developing party is developing both services that communicate with each other. They can choose to not support this.

I think they would need to demonstrate why that cannot be supported...

temporary session tokens should be generated and used instead of sending the credential on each connection.

I don't understand this. Why would this be better?

Temp session tokens are better than sending a credential each time. This is how OAuth2/OpenID service to service authentication is supposed to work.

@Sjord do you think you could propose alternative wording.

[elarlang]

Related, potential duplicate requirement: https://github.com/OWASP/ASVS/issues/1522

[tghosth]

hi @Sjord, any thoughts on my comment here: https://github.com/OWASP/ASVS/issues/1032#issuecomment-1559095414

[Sjord]

No, I don't really have anything to add other than what I already described above.

[tghosth]

Ok so @Sjord @elarlang what do you think about this:

Verify that service authentication uses either mTLS or a credential (such as an API key or password) which is unique to that service and rotatable. If a credential is being used, temporary session tokens should be generated and used instead of sending the credential on each connection.

[elarlang]

Temp session tokens are better than sending a credential each time. This is how OAuth2/OpenID service to service authentication is supposed to work.

If an application uses authentication for every request does it make "not valid"? Maybe "can be" instead of "should be"?

[tghosth]

Maybe:

Verify that service authentication uses either mTLS or a credential (such as an API key or password) which is unique to that service and rotatable. If a credential is being used, temporary session tokens should be generated and used instead of sending the credential on each connection unless there is a good reason why this is not possible.

[elarlang]

As a developer I want to ask - what is the good reason why I need to use sessions in this situation?

I think we need to be clear with that.

[tghosth]

So my preferred wording would be

Verify that service authentication uses either mTLS or a credential (such as an API key or password) which is unique to that service and rotatable. If a credential is being used, temporary session tokens should be generated and used instead of sending the credential on each connection unless there is not supported by the 3rd party.

But @Sjord was worried this was too easy to get out of...

[elarlang]

I re-read entire communication here... and it did not help.

I think we need to make clear wording - is the requirement for the application which providing the machine-to-machine service or the one who is using it.

If it is for using, then how much there is for the application to say, how the communication should be done - it just can use whatever way it is provided. Or should we have requirement to set some limitation here?

I don't see the reason, why you need to have creating a session overhead for every situation. It makes sense when you have multiple requests to handle with the same client over short period of time. But if it's some data sync once per day and it's done with one request, do I really need to have this session overhead?

[tghosth]

I re-read entire communication here... and it did not help.

I think we need to make clear wording - is the requirement for the application which providing the machine-to-machine service or the one who is using it.

If it is for using, then how much there is for the application to say, how the communication should be done - it just can use whatever way it is provided. Or should we have requirement to set some limitation here?

OK so I see your point about making this clearer. What do you think about the following reword/split?

• Verify that for a service designed to be consumed by other services, authentication uses either mTLS or a credential (such as an API key or password) which is unique to that service and rotatable. If a credential is being used, temporary session tokens should be generated and used instead of the consumer sending the credential on each connection.
• Verify that consumers of a service are configured to use the most secure authentication option provided by the service being consumed.

I don't see the reason, why you need to have creating a session overhead for every situation. It makes sense when you have multiple requests to handle with the same client over short period of time. But if it's some data sync once per day and it's done with one request, do I really need to have this session overhead?

I see your point but I think that is leading practice for service to service authentication, e.g. using OIDC and we should mandate it in particular for service developers (rather than service consumers).

[elarlang]

The wording is nice and clear to separate consuming and providing a service.

If a credential is being used, temporary session tokens should be generated and used instead of the consumer sending the credential on each connection.

how it increases the risk if it is not done that way?

[jmanico]

The wording is nice and clear to separate consuming and providing a service.

If a credential is being used, temporary session tokens should be generated and used instead of the consumer sending the credential on each connection.

how it increases the risk if it is not done that way?

More chance of credential exposure.

[elarlang]

Do I missing something here?

Solution a)

1. A makes request to service B, request also contains credentials
2. B validates credentials (authentication) and gives response

Solution b)

1. A makes authentication request to service B - sending credentials
2. B validates credentials (authentication) and gives back session token
3. A makes request to service B, request also contains session token
4. B validates session token and gives back response

How solution a is worse and gives more opportunities to leak credentials?

[tghosth]

You are correct if this is just one communication. However, if there will be multiple communications between A and B then this makes a difference.

[elarlang]

You are correct if this is just one communication. However, if there will be multiple communications between A and B then this makes a difference.

... and this was exactly what I pointed out here: https://github.com/OWASP/ASVS/issues/1032#issuecomment-1723691604

I don't see the reason, why you need to have creating a session overhead for every situation. It makes sense when you have multiple requests to handle with the same client over short period of time. But if it's some data sync once per day and it's done with one request, do I really need to have this session overhead?

[tghosth]

Ok so we could do this but I am not sure it is ideal:

Verify that for a service designed to be consumed by other services, authentication uses either mTLS or a credential (such as an API key or password) which is unique to that service and rotatable. If a credential is being used and interaction with the service involves more than one connection per session, temporary session tokens should be generated and used instead of the consumer sending the credential on each connection.

Verify that consumers of a service are configured to use the most secure authentication option provided by the service being consumed.

Thoughts @elarlang ?