4 ms·

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire

by bob1029 7mo ago

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire 512 bit token still fits in an x86 cache line. Comparing the whole sequence won't show up in any profiler session you will ever care about. If you want aspects of the token to be inspectable by intermediaries, then you want json web tokens or a similar technology. You do not want to conflate these ideas. JWTs would solve the stated database concern. All you need to store in a JWT scheme are the private/public keys. Explicit tracking of the session is not required.

notpushkin 7mo ago
> 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 7mo ago
  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 7mo ago
    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 7mo ago
      That sounds like it's only helpful for ddos mitigation, in which case the attacker could trivially synthesize a correct checksum.
      - phire 7mo ago
        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 7mo ago
        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 7mo ago
        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 7mo ago
        Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)
        phire 7mo ago
        I don't think it counts as a signature, because it can't be verified without revealing the same secret used to create it.
        7mo ago
- rrr_oh_man 7mo ago
  > I assume the product is big enough Experience tells otherwise
- locknitpicker 7mo ago
  > 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.
vjay15 7mo ago
Hello bob! the checksum is for secret scanning offline and also for rejecting api keys which might have a typo (niche case) I just was confused regarding the JWT approach, since from the research I did I saw that it's supposed to be a unique string and thats it!
- arethuza 7mo ago
  "for rejecting api keys which might have a type" - assuming that is meant by to be "typo" - won't they get rejected anyway?
  - vjay15 7mo ago
    it's just an added benefit, I don't have to make a DB call to verify that :)
    - huflungdung 7mo ago
      [dead]
- petterroea 7mo ago
  I may be naive but I can't imagine anyone typing an api key by hand. Optimizing for it sounds like premature optimization, surely stopping the less than one in a million HTTP request with a hand-typed API key from reaching the db isn't worth anything
  - vjay15 7mo ago
    if not for typo, then I can use for secret scanning then :)
    - petterroea 7mo ago
      Good point!
- bob1029 7mo ago
Hendrikto 7mo ago
JWTs solve some problems but then come with a lot of their own. I do not think they should be the goto solution.

by bob1029 7mo ago

notpushkin 7mo ago

> 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 7mo ago
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 7mo ago
  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 7mo ago
    That sounds like it's only helpful for ddos mitigation, in which case the attacker could trivially synthesize a correct checksum.
    - phire 7mo ago
      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 7mo ago
        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 7mo ago
        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 7mo ago
        Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)
        phire 7mo ago
        I don't think it counts as a signature, because it can't be verified without revealing the same secret used to create it.
        7mo ago
rrr_oh_man 7mo ago
> I assume the product is big enough Experience tells otherwise
locknitpicker 7mo ago
> 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.

vjay15 7mo ago

Hello bob! the checksum is for secret scanning offline and also for rejecting api keys which might have a typo (niche case) I just was confused regarding the JWT approach, since from the research I did I saw that it's supposed to be a unique string and thats it!

arethuza 7mo ago
"for rejecting api keys which might have a type" - assuming that is meant by to be "typo" - won't they get rejected anyway?
- vjay15 7mo ago
  it's just an added benefit, I don't have to make a DB call to verify that :)
  - huflungdung 7mo ago
    [dead]
petterroea 7mo ago
I may be naive but I can't imagine anyone typing an api key by hand. Optimizing for it sounds like premature optimization, surely stopping the less than one in a million HTTP request with a hand-typed API key from reaching the db isn't worth anything
- vjay15 7mo ago
  if not for typo, then I can use for secret scanning then :)
  - petterroea 7mo ago
    Good point!
bob1029 7mo ago

Hendrikto 7mo ago

JWTs solve some problems but then come with a lot of their own. I do not think they should be the goto solution.