1.6.4 requirement is too complicated to understand

[belalena]

1.6.4 Verify that symmetric keys, passwords, or API secrets generated by or shared with clients are used only in protecting low risk secrets, such as encrypting local storage, or temporary ephemeral uses such as parameter obfuscation. Sharing secrets with clients is clear-text equivalent and architecturally should be treated as such.

I'm not a native english speaker and it's completely not clear for me what does it mean:

• "are used only in protecting low risk secrets" - symmetric keys, passwords and so on are used to protect low risk secrets ( such as ..)? and what about high risk secrets?
  OR the meaning is "are used in protected low risk way (such as ...)";

• "temporary ephemeral uses such as parameter obfuscation" - temporary = parameter obfuscation? OR parameter obfuscation should be temporary measure?

"Sharing secrets with clients is clear-text equivalent and architecturally should be treated as such." - what is "as such"?

**why not to form it smth like

Verify that symmetric keys, passwords, API secrets, keystorages, certificates and other secrets shared with clients are used in protected low risk way (for example, they are stored in encrypted storage on the client side, they are temporary, they are obfuscated)..**

[m8urnett]

Is this wording more clear?

Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.

[belalena]

Is this wording more clear?

Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.

Sounds much easier to understand. Thank you. BUT if the meaning is as you wrote then I didn't catch what to use instead of symmetric keys, passwords, or API tokens to access sensitive data ? Can you please point me to req. about it or so?

[tghosth]

Hi @belalena The point is that symmetric secrets which the client has access to should not be used to protect sensitive data. Instead, a secret which is not shared with the client should be used to protect sensitive data.

Does that make more sense?

[vanderaj]

This makes sense as an inclusion to 4.0.2

[jmanico]

Change submitted 80498cf

[aspnetde]

Hi together,

I just stumbled across that item as it made its way into version 4.0.3 of the ASVS:

1.6.4: Verify that the architecture treats client-side secrets–such as symmetric keys, passwords, or API tokens–as insecure and never uses them to protect or access sensitive data.

I see a lot of scenarios where this makes absolutely sense, e.g., keys of third-party APIs which should not be shared with the client under any circumstances. However, there are also scenarios where this phrasing appears to be a little too broad/generic. E.g., consider a web application which implements end-to-end encryption with a zero-knowledge policy for the server and the client app acting as "ends". In that case the web app needs to deal with keying material etc. by definition. There's a lot of arguments that can be made against such a scenario in the first place, of course, but it's nothing which is inherently bad or wrong.

So I'd suggest to make that item a bit more precise.

@tghosth

[elarlang]

I reopen it for @aspnetde

In general - comments in already closed old (in this case 2years+) issues may not get noticed and it makes sense to open new issue