ItsDangerous | Hacker News Reader

ItsDangerous

itsdangerous.palletsprojects.com

125 pointstosh30 comments

Once upon a time, the company I was working at was going through an acquisition and in part of the due diligence process the acquirer asked us for a complete list of all software and dependencies in our technology stack. The only one my team heard back about was ItsDangerous.

What did you hear about it?

They were asking what it was for. I suspect the person reviewing the list had no idea what they were doing. If there's going to be security threat lurking in there its not going to be in the package named "itsdangerous", its going to in the one with a typo in the name.

on the other hand, just on the off chance that it is malware, you really don't want to be the guy who didn't ask about the package called "itsdangerous"

I wonder about OP's reasoning for submitting this to HN.

`itsdangerous` has been around for a while and is actually required by `flask`.

I am researching best practices for signing of data for web services (in JavaScript) and remembered that I was using a library with flask at a hackathon a few years ago and that it had a sword illustration on the website but couldn’t find it (but eventually did now).

Nowhere in the HN guidelines[1] is it required (or even recommended) for a submission to be new or even recent - there are popular submissions going back to the 1900's and others that have hit the front page a dozen times because they're timeless or little-known.

The fact that the submission has 73 upvotes (as of this comment) and that I found it novel and interesting suggests that it's rather on-topic, and interesting and provides value to others, and it's certainly "Anything that good hackers would find interesting. [...] anything that gratifies one's intellectual curiosity."

Meanwhile, I don't find much value in your questioning why a popular post was submitted in the first place.

[1] https://news.ycombinator.com/newsguidelines.html

The reminder that the library is used in Flask was helpful even if the questioning wasn’t.

Please edit swipes like that last bit out of your comments here. Your other points are fine.

https://news.ycombinator.com/newsguidelines.html

My apologies. You have my permission to edit it - I'm past my edit window now.

How does this differ from JWT? (sincere question not having deep knowledge about JWT either)

This is much simpler than JWT; you'd have a hard time to implement this incorrectly as opposed to JWT. I'm not in the loop, but JWT also used to specify an entire tirefire for crypto algorithms. Probably still does.

I've used PASETO in place of JWT for this kind of thing before. Interested to know how it compares.

Does this support a known standard, or is it just its own thing.

JWT specified all the crypto algorithms; even future ones. They did not intend people to accept more then a very small subset. This was insufficiently well communicated.

Where? RFC 7519 states pretty specifically that only HMAC SHA-256 "none" MUST be implemented. The rest were left up to devs as optional.

I don't think it means what you're suggesting, but maybe I'm misunderstanding you. The previous paragraph in the RFC says:

> Applications using this specification can impose additional requirements upon implementations that they use. For instance, one application might require support for encrypted JWTs and Nested JWTs, while another might require support for signing JWTs with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm ("ES256").

In the next paragraph it says:

> Of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by conforming JWT implementations.

They're making the distinction here between JWT implementations (i.e. libraries) and applications that use JWT. Nothing mandates that applications must accept the "none" method. The earlier paragraph gives specific usage examples in which a small subset of options are allowed by the application. That is the intended use.

In this later paragraph they're just establishing a baseline of encryption support in libraries; i.e., what is the minimal set of choices that a library can offer to an application. Applications are still expected to actually choose.

It still does. In practice one of the first things you do is to only accept the specific crypto algorithms you actually need to use. Libraries don't get that luxury because they need to be generic, but at least you as the web service implementer can do it.

The big problem was that JWTs specifies the signature algorithm alongside the signature. Some naive implementations allowed all supported algorithms by default... one of which is "none". So an attacker was able to create a key with no signature and the application would accept it. I think nowadays all implementations require you to specifically whitelist the allowed algorithms.

But yeah, JWTs (technically JWS) overlaps with ItsDangerous, but ItsDangerous is much simpler and has fewer footguns.

It predates JWTs by several years. In practice is is used the same way is as symmetrically signed JWTs though by default with HMAC-SHA-1 vs HMAC-SHA256. It can support a timestamp (`iat` for JWT) to implement expiry but not an actual `exp`; nor `aud` and the other common fields. It also dose not handle encryption or asymmetric signing. Whilst these all sound like drawbacks they do give it simplicity which is also a useful feature.

Seems like this is just an hmac version of shasum, neat tho.

Reply on news.ycombinator.com