> The checksum is pointless because an entire 512 bit token still fits in an x86 cache line

I suppose it’s there to avoid round-trip to the DB. Most of us just need to host the DB on the same machine instead, but given sharding is involved, I assume the product is big enough this is undesirable.

▲

phire 2 days ago | parent | next [-]

You need to support revocation, so I'm not sure it's ever possible to avoid the need for a round trip to verify the token.

▲

kukkamario 2 days ago | parent [-]

The point of the checksum is to just drop obviously wrong keys. No need to handle revocation or do any DB access if checksum is incorrect, the key can just be rejected.

▲

ben-schaaf 2 days ago | parent [-]

That sounds like it's only helpful for ddos mitigation, in which case the attacker could trivially synthesize a correct checksum.

▲

phire 2 days ago | parent [-]

You don't have to use a publicly documented checksum.

If you use a cryptographically secure hashing algorithm, mix in a secret salt and use a long enough checksum, attackers would find it nearly impossible to synthesise a correct checksum.

▲

ben-schaaf 2 days ago | parent [-]

I don't follow. The checksum is in "plain text" in every key. It's trivial to find the length of the checksum and the checksum is generated from the payload.

Others have pointed out that the checksum is for offline secret scanning, which makes a lot more sense to me than ddos mitigation.

▲

phire 2 days ago | parent [-]

I'm not sure it's a good idea.

But it's trivial to make a secret checksum. Just take the key, concatenate it with a secret 256-bit key that only the servers know and hash it with sha256. External users might know the length of the checksum and that it was generated with sha256. But if they don't know the 256-bit key, then it's impossible for them to generate it short of running a brute force attack against your servers.

But it does make the checksum pretty useless for other usecases, as nobody can verify the checksum without the secret.

▲

ben-schaaf a day ago | parent [-]

Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)

▲

phire a day ago | parent [-]

I don't think it counts as a signature, because it can't be verified without revealing the same secret used to create it.

	▲	ben-schaaf a day ago \| parent [-]
		You're right, the correct term seems to be MAC (Message Authentication Code).

▲

locknitpicker 2 days ago | parent | prev | next [-]

> I suppose it’s there to avoid round-trip to the DB.

That assumption is false. The article states that the DB is hit either way.

From the article:

> The reason behind having a checksum is that it allows you to verify first whether this API key is even valid before hitting the DB,

This is absurdly redundant. Caching DB calls is cheaper and simpler to implement.

If this was a local validation check, where API key signature would be checked with a secret to avoid a DB roundtrip then that could see the value in it. But that's already well in the territory of an access token, which then would be enough to reject the whole idea.

If I saw a proposal like that in my org I would reject it on the grounds of being technically unsound.

▲

rrr_oh_man 2 days ago | parent | prev [-]

> I assume the product is big enough

Experience tells otherwise