4 ms·
Who is the author? It's just a bare Google Doc AFAICT. Some quick notes: random tokens do rely, broadly speaking, on cryptography, as the token must be genera
by sk5t 9y ago
Who is the author? It's just a bare Google Doc AFAICT.
Some quick notes: random tokens do rely, broadly speaking, on cryptography, as the token must be generated by a cryptographically strong (P)RNG.
Signing and encryption are conceptually different ideas, don't mix them as in the description of the stateless session cookie. There's a great old Matasano blog post in the style of a play about this...
A more complete consideration of authn techniques would include mutual certificate ("SSL") authn, as well as signed-request approaches not using a shared secret.
- cygned 9y agoThis one. https://news.ycombinator.com/item?id=14290234 https://news.ycombinator.com/item?id=14290234
- ksri 9y agoAuthor here, though not the one who submitted it. >> random tokens do rely on cryptography True. Random tokens do need a cryptographically strong PRNG. But when I wrote no cryptography, I meant there is no encryption or signatures. The token is used as a key to a server side data structure. >> Signing and encryption are conceptually different ideas, don't mix them Not sure where I mixed them? A stateless session cookie can be signed or it can be encrypted - both are valid. A signed cookie would let clients see the contents, but wouldn't let them modify it. An encrypted cookie would make it opaque to the clients.
- sk5t 9y agoIf you're passing sensitive data to the client (the cookie) it's a hazard to encrypt only without a signature. _Always_ sign and verify, sometimes encrypt before signing / decrypt after verifying signature.
- gandalfu 9y agoWhy certificate based authentication wasn't included? The server stores the public cert from all clients and uses it to authenticate at the transport layer. No shared secrets either.
- ksri 9y agoYes, that's a miss. I'll add it as another option. Thanks!