Hacker News Reader

Comment by jarym | Hacker News Reader

Never read such nonsense masquerading as an authoritative piece of information.

Author clearly doesn't appreciate that the ultimate truth of any authentication scheme is you should not trust anything from the user. So what if you take away a clients ability to specify what algorithm a piece of data is signed or encrypted with - if you blindly just accept whatever a client did and proceed then you're always gonna find yourself vulnerable.

Intel didn't use JWT tokens or pass a client header - they just trusted what the client sent and landed themselves in the same mess. I make the point to illustrate that what real security pros do is make sure basic checks like validating user input is done regardless of what specification or algorithm is involved.

View on HN

Security is half a technical problem and half a usability problem (for developers). We need more emphasis on the usability half.

For example, we should be doing everything we can to ease the mental burden of writing secure code. Whenever we can reasonably eliminate the possibility of a vulnerability, we should. Even if someone has to be an idiot to make the mistake, just don't make it possible to make the mistake in the first place. We should also try to reduce the amount of potentially-malicious input, reduce the amount of options and special cases, etc. Simplify.

Usability improvements pay off multiple times. They make developers' jobs easier because there's less code to write and the code that does get written is easier to reason about. They make security auditors' jobs easier because there are fewer "dumb" mistakes to check for, and that means more of the audit time can be spent looking for deeper flaws.

(Nitpick about the phrase "validating user input": The user's input should never be trusted, but that doesn't mean we should write code to try and decide whether the user's input is "safe" or "unsafe", as that can be impossibly-hard depending on what's happening after the validation check. The code should just be secure no matter what the input is.)

> Usability improvements pay off multiple times.

There's a bit in Google's paper about the Chubby lock service where they note that a big reason for the success of that project was all the concessions they made for developer usability.

Even his history of train coupling was lopsided. I know nothing about the subject, but this:

> Still, the railroads stuck with them because link-and-pin couplers were cheap. You could imagine excuses being made about the people who died...

You have to think that every train coupling on every train at the same time is a pretty big and very real excuse. No single operator could change first, unless they were a near monopoly. I'd guess that railroad companies weren't big fans of their trained employees getting crushed.

So tired of the trope that big evil corporations put zero value on the lives of their employees. Fact is, they value them as much as the replacement cost + cleanup cost + downtime + bad PR, which in many cases is pretty high. Also, sometimes the owners actually aren't evil monsters.

They got $50 million from the government as a carrot to switch

These points are covered in the article, and the library I wrote makes it impossible to parse a token without performing verification with a secret key

Yes I read. However, you've failed to grasp a few things:

1. The client should not get to 'choose' which algo it uses, it merely states what algo it did use. Emphasis should be on the server to verify that the client didn't do (or claim to do) something bad.

2. What happens if in 5 years time the algo you've standardised on is suddenly comprisable? You've ripped out the mechanism that updated clients could theoretically use to signify that they're using a newer algorithm. Take for example Git and its recent SHA collision issue.

3. By emphasising that 'clients should not get to choose', you're making the case that the choice is of itself a weakness it is not. The weakness is often in how inputs are processed (and far more often than any weakness in algorithms).

I point out numerous cases where the server made a mistake in verifying the algorithm specified by the client. This is the point of reducing the complexity of the interaction

If you are using JWT and someone breaks SHA2, you still have to worry about downgrade attacks. To evade downgrade attacks, you'll have to detect the protocol the client sends, and reject tokens that specify SHA2 or below. Or, roughly the same position you'd be in with one good algorithm: still in need of a backwards incompatible upgrade

This concern was always supposed to be handled by algorithm whitelists. The _intent_ was that services would consult a whitelist of algorithms before accepting a particular JWT.

The idea was certainly not that services blindly accept any token from every algorithm shipped in the library.

Your browser supports TLS 1.0, should you throw it out?

> If someone breaks SHA2...

JWT has a built-in mechanism for handling this: expirations.

There's no "better TLS" out there for shipping a tool that connects to millions of different servers. There are many better options than JWT.

Unlike JWT, hundreds of the world's best security engineers at various browser companies are working on mitigating the situation as well as possible.

Indeed, however, consider that servers can and do limit which TLS versions and cipher suites they accept.

Expirations are not really relevant to this. It won't prevent a user from forging new tokens with a different expiration (using a broken algorithm), nor will it somehow magically make the original token unreadable.

The expiration is just an additional value in the payload that the implementation is supposed to check against.

That's how I always implemented JWT, but I'm pretty sure the lazy implementer would get that wrong. I'm with you that a protocol should include some versioning mechanism, but it probably shouldn't have as many knobs as JWT has right now.

The decision to include RSA was misguided, and there's no point in letting users choose the size of the hash or whether to use key-wrapping or not (in JWE - the answer is always use key-wrapping with GCM when in doubt, 96 bits nonces are not long enough if you send many messages). There are other confusing knobs which shouldn't have been there.

It's best to go the NaCl way and choose 1 algorithm considered best-in-class for each type of crypto, and leave space for adding new algorithms in the future when the old algorithm becomes compromised. Cypher breakdown events like Shapocalypse don't happen out of the blue. We usually get gradually improving attacks at least 5-10 years before that breakdown happens (SHA1 had weaknesses found as early as 2005).

Literally, someone has created poor implementations of TLS and SSL that have caused massive security issues for the world, (heartbleed, poodle, freak, beast) but you seem to have glossed over that detail and recommended it anyway.

It's deployed onto billions of browsers already, and the only way to talk to e.g the Twitter API. We don't really have a choice about it. But if you want you can read tptacek on it: https://gist.github.com/tqbf/be58d2d39690c3b366ad

Side note: that's a cool list

Reply on news.ycombinator.com