2

Applications that use cryptographically signed information for multiple purposes have the risk that one piece of signed information can be exchanged with another. When you use JWTs as session tokens, and you use JWTs as password reset tokens, the password reset tokens should not be valid as session tokens. So a piece of signed information should be valid for only a specific purpose.

I am looking how to describe this more succintly, to include this in the ASVS. What is the name of this attack?

I found one example: Missing Required Cryptographic Step Leading to Sensitive Information Disclosure in TYPO3 CMS · CVE-2020-15098 · GitHub Advisory Database. Are there any more example?

The purpose of the signed data can be set using the "additional data" in AEAD ciphers, and partially in the audience field in a JWT. Is there a better name for such a field?

3
  • 1) JWT provides identity of the party that is sending it. Anything else is just poor design.
    – mentallurg
    Apr 8 at 21:01
  • 2) If you want to use JWT for password reset only, set corresponding claim that allows only that. I don't understand what problem are you trying to describe.
    – mentallurg
    Apr 8 at 21:04
  • 3) "cryptographically signed information for multiple purposes ... signed information can be exchanged with another" - Such problem does not exist. A) This is generalization without any reason. If you mean JWT, please write JWT and don't generalize it. B) The acceptance of document depends on the party that accepts it. It is one of the common problems that some services do not properly validate JWT. If multiple services accept the same claim, it is their right to do that. If you want to use JWT for particular purpose, it should contain corresponding restriction, namely, corresponding claims.
    – mentallurg
    Apr 8 at 21:14

2 Answers 2

1

The purpose of the signed data can be set using the "additional data" in AEAD ciphers, and partially in the audience field in a JWT. Is there a better name for such a field?

This mechanism is sometimes called domain separation.

In SP 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, ParallelHash | CSRC:

Domain Separation - For a function, a partitioning of the inputs to different application domains so that no input is assigned to more than one domain.

cSHAKE has a "Customization String" for this purpose:

The cSHAKE function also includes an input string (S) to allow users to customize their use of the function. For example, someone using cSHAKE128 to compute a key fingerprint (the hash value for a public key) might use:

cSHAKE128(public_key, 256, "", "key fingerprint"),

where "key fingerprint" is a customization string S.

key derivation - What is meant by domain separation in the context of KDF? - Cryptography Stack Exchange

This document uses "Context Labels" for domain separation.

This document obtains domain separation using "domain separation tags".

The Kyber paper simply calls this parameter the "domain separator".

RFC8032 specifies Ed25519ctx with a "context input".

ORCHID uses a "Context Identifier", but that is a randomly generated value, not a static string.

0

The purpose of the signed data can be set using the "additional data" in AEAD ciphers, and partially in the audience field in a JWT. Is there a better name for such a field?

In the context of block ciphers, this is sometimes called the tweak. A tweakable block cipher gives a different permutation for a different tweak value. An exposed tweak value does not compromise security. It can for instance be used to encrypt session tokens and password resets with the same key, but a different tweak, to avoid exchanging one for the other.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .