Hacker News Reader

Comment by saynsedit | Hacker News Reader

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.

View on HN

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.

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.

> 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-algorit...

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?

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.

Asking you to disclose your identity was only a suggestion and it was offered at your discretion, appealing to your potential desire to be a Good Samaritan.

My sincere intent was not to offend you but protect you from yourself. I had already offered what I thought was sufficient explanation for the attack and I felt there were no further options.

I did not mean to offend you but since I have I apologize. I don't believe one's self-worth or employability is based on their expertise in computer security but I can see how that can be implied by what I wrote and I was wrong to be careless with my language online. Honestly I am no expert either. I just hope we can all cooperate, put our egos aside, remain humble in our limited knowledge, keep an open mind and stay focused on the facts to build more secure systems.

Peace and well wishes to you and your family.

Reply on news.ycombinator.com