4 ms·
That sounds like a time-space trade-off to me. I'd think cryptographic signature verification would be more expensive computationally than a cache lookup and co
by bradleyjg 10y ago
That sounds like a time-space trade-off to me. I'd think cryptographic signature verification would be more expensive computationally than a cache lookup and compare, but not require much space. Also, and maybe this is the key part, it would be more distributable since you don't need shared state.
- mark242 10y agoYes; and CPU is cheap as hell. Round trips to a cache are expensive.
- cpeterso 10y agoAlso, CPU tasks like authenticating a message are cheap to scale horizontally. A cache is a centralized bottleneck.
- carterehsmith 10y agoThat depends on where your cache is. If your cache is on a separate box and you have to make a network round trip, yeah it is expensive. But if your cache is in-process, the access is cheap.
- tptacek 10y agoCryptographic signature verification can be expensive, but the previous commenter (and, to be fair, pretty much the whole software industry) is abusing the term "signature". Really, what we're talking about is cryptographically authenticated messages. Verifying an authenticator is extremely fast.
- dpark 10y agoCan you clarify what the difference is here? How do you verify an authenticator without verifying a signature?
- tptacek 10y agoPedantically, a "signature" is the product of a public key signature algorithm. It's what you use when you have multiple and/or anonymous verifiers. An authenticator is the product of an authentication algorithm, which can be as simple as a keyed SHA-3 hash (a hash over the data to be authenticated and a key known only to the verifier). Session tokens virtually never use signatures. The only party that needs to verify them is the serverside of the application that generates them; they're opaque to clients.
- dpark 10y agoSo you're assuming the session tokens are authenticated with a shared key. I guess that makes sense from a perf standpoint. It seems iffy from an isolation standpoint, though. I wouldn't think you would want every server holding effectively global auth keys. Edit: I guess this is actually a good case for the 2CH described here. The long-session cookie could be cryptographically signed, while the short-session cookie could be authenticated with a shared key that gets rotated frequently so that a leak of the key cannot cause a long-term compromise.
- tptacek 10y agoI don't know what you mean by "isolation", but virtually every mainstream system that stores secrets in tokens uses MAC constructions, not signatures. Signatures are much more complicated and dangerous. Don't ever use public-key crypto unless you absolutely need it.
- StavrosK 10y agoHe means that the auth key has to be shared between N servers, ie you can't have a scenario where a server can verify all the others' signatures but can only issue its own.
- dpark 10y agoIsolation meaning that every web server cannot issue authenticated cookies for arbitrary users. I'm clearly not a security expert but that seems to greatly increase the damage scale of a single web server breach. Also, how would you store a secret in a token without encryption? Or was that just a misstatement?