4 ms·

This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impe

This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impersonate a user.

jsmeaton 10y ago
The signature is already available - it's literally appended to the output. Verifying the signature is done by hashing the body with a secret (key) and comparing it to the known signature. "Known" === HMACSHA256(payload, secret) You already know the left hand side. How would a constant time comparison protect you from a timing attack in this scenario? It wouldn't. The signature is known, the payload is known, but the secret is not known. That means you'd have to attack the secret, which you could even do offline. By iteratively changing the secret, even if you were to get the first half of the hash right, the next character you change would potentially change every single character in the output. JWT/JWS does not concern itself with keeping the token secret or providing encryption. It's only concern is message authentication. If you leak your token, someone else can impersonate you, just like if you'd leaked your session cookie. The only viable attack on the scheme is to brute force (or discover) the secret, which would allow you to sign a message of your choosing. Once you can sign a message as if you were the server, then you may impersonate anyone you choose.
- deleted 10y ago
  [deleted]
- saynsedit 10y ago
  First, the signature isn't necessary public. As you said, there is a separation of concerns. If the JWT authentication is wrapped underneath encryption, then the signature is private. In either case, public or private, an attacker shouldn't be able to create their own tokens at their leisure. Token theft is guarded against using encryption, token creation is guarded against using constant-time compare. Encryption cannot protect timing attacks. Again, the hash secret is irrelevant in the case of trying to generate a token for a specific user. The signature for a specific user payload is an opaque hash that can be discovered via timing analysis. The secret hash function that was used to produce it is not important if timing information is available. If you cannot understand this, please I beg you, do NOT design crypto systems. If you'd like to be an even better Good Samaritan, please disclose your identity to the community. This may protect your future employer and their customers from a breach.
  - deleted 10y ago
    [deleted]
  - jsmeaton 10y ago
    > If you cannot understand this, please I beg you, do NOT design crypto systems. If you'd like to be an even better Good Samaritan, please disclose your identity to the community. This may protect your future employer and their customers from a breach. First let me say that I believed we were having a decent conversation until this comment right here. You're personally attacking me at this point. I am not designing crypto. In my first message I stated multiple times that those were my thoughts. My identity isn't hidden - if you care to look through my history. Your account is 20 days old, and you're talking to me about making my identity public? Anyhow, I now understand the attack you've been describing. I misunderstood the attack, thinking you wanted to be able to sign any message of your choosing. Rather, the attack is focused on iteratively changing the signature of a message until the server confirms it. I was wrong, you were right. The spec for JSON Web Algorithms (JWA)[0] confirms this. [0] https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-3.2 https://tools.ietf.org/html/draft-ietf-jose-json-web-algorit...
    - saynsedit 10y ago
      It wasn't a personal attack. Computer security is a minefield of unknown unknowns. Individuals that aren't deeply familiar with all the modern attacks or aren't skeptical of unknown attacks shouldn't design crypto, has nothing to do with you. Some people need a document to tell them what the secure thing to do is, security analysts don't. I would beg anyone who claims that timing attacks against signatures don't exist to not build crypto systems. In the same way I would beg anyone who denies climate change to not make public policy, wouldn't you?
      - jsmeaton 10y ago
        It wasn't the "don't build security" that was the attack. It was "be a good boy and tell us who you are so we're protected from your incompetence" that I'm taking issue with. I think it's particularly unfair seeing as your original reply to me was so brief that I missed the crucial point. Anyhow, we're done here.

This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impersonate a user.

jsmeaton 10y ago

The signature is already available - it's literally appended to the output. Verifying the signature is done by hashing the body with a secret (key) and comparing it to the known signature. "Known" === HMACSHA256(payload, secret) You already know the left hand side. How would a constant time comparison protect you from a timing attack in this scenario? It wouldn't. The signature is known, the payload is known, but the secret is not known. That means you'd have to attack the secret, which you could even do offline. By iteratively changing the secret, even if you were to get the first half of the hash right, the next character you change would potentially change every single character in the output. JWT/JWS does not concern itself with keeping the token secret or providing encryption. It's only concern is message authentication. If you leak your token, someone else can impersonate you, just like if you'd leaked your session cookie. The only viable attack on the scheme is to brute force (or discover) the secret, which would allow you to sign a message of your choosing. Once you can sign a message as if you were the server, then you may impersonate anyone you choose.

deleted 10y ago
[deleted]
saynsedit 10y ago
First, the signature isn't necessary public. As you said, there is a separation of concerns. If the JWT authentication is wrapped underneath encryption, then the signature is private. In either case, public or private, an attacker shouldn't be able to create their own tokens at their leisure. Token theft is guarded against using encryption, token creation is guarded against using constant-time compare. Encryption cannot protect timing attacks. Again, the hash secret is irrelevant in the case of trying to generate a token for a specific user. The signature for a specific user payload is an opaque hash that can be discovered via timing analysis. The secret hash function that was used to produce it is not important if timing information is available. If you cannot understand this, please I beg you, do NOT design crypto systems. If you'd like to be an even better Good Samaritan, please disclose your identity to the community. This may protect your future employer and their customers from a breach.
- deleted 10y ago
  [deleted]
- jsmeaton 10y ago
  > If you cannot understand this, please I beg you, do NOT design crypto systems. If you'd like to be an even better Good Samaritan, please disclose your identity to the community. This may protect your future employer and their customers from a breach. First let me say that I believed we were having a decent conversation until this comment right here. You're personally attacking me at this point. I am not designing crypto. In my first message I stated multiple times that those were my thoughts. My identity isn't hidden - if you care to look through my history. Your account is 20 days old, and you're talking to me about making my identity public? Anyhow, I now understand the attack you've been describing. I misunderstood the attack, thinking you wanted to be able to sign any message of your choosing. Rather, the attack is focused on iteratively changing the signature of a message until the server confirms it. I was wrong, you were right. The spec for JSON Web Algorithms (JWA)[0] confirms this. [0] https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-3.2 https://tools.ietf.org/html/draft-ietf-jose-json-web-algorit...
  - saynsedit 10y ago
    It wasn't a personal attack. Computer security is a minefield of unknown unknowns. Individuals that aren't deeply familiar with all the modern attacks or aren't skeptical of unknown attacks shouldn't design crypto, has nothing to do with you. Some people need a document to tell them what the secure thing to do is, security analysts don't. I would beg anyone who claims that timing attacks against signatures don't exist to not build crypto systems. In the same way I would beg anyone who denies climate change to not make public policy, wouldn't you?
    - jsmeaton 10y ago
      It wasn't the "don't build security" that was the attack. It was "be a good boy and tell us who you are so we're protected from your incompetence" that I'm taking issue with. I think it's particularly unfair seeing as your original reply to me was so brief that I missed the crucial point. Anyhow, we're done here.