undefined | Better HN

0 pointslifeisstillgood12y ago0 comments

>That's we use existing crypto libraries.

That's how we implement flaws in the process, around crypto libraries. The price of session-cache lookups is the price paid not to worry there is a serious undiscovered security flaw waiting for you around the corner.

Its a price you have to decide if its worth paying.

0 comments

4 comments · 1 top-level

lucian190012y ago· 3 in thread

The crypto library should be given the unparsed payload and either complain the signature is invalid or give you the parsed payload.

There is no price to pay in apps, since there are such crypto libraries for most languages.

taway201212y ago

You're basically saying that if everything works as expected, then a signed cookie is no different than an opaque handle to server-side data. But it doesn't answer (IMHO) the point that there are more things that can go wrong with a signed cookie. IMHO, YMMV.

Here are some challenges that occurred to me in a signed-cookie approach:

1) How is the signing key generated? If it's the output of a weak PRNG, maybe it can be bruteforced?

2) Where is it stored? Hard-coded in source? Data file? Command line param?

3) Same signing key on multiple servers?

4) Do you regenerate the keys periodically?

5) What if a team member leaves. Do signing keys get regenerated?

With a DB-based approach, your session data just piggybacks on the server security infrasturcture that you would have built anyway.

JoachimSchipper12y ago

You're not wrong, but note that the usual random-handle-to-server-side-state still needs good random (1) that is not correlated across servers (equivalent of 3; don't spin up VMs with the same data in the random pool!) And if you have long-lived admin sessions, you may need to think about (5) too, especially if the company does not own all the hardware that employees use.

lifeisstillgoodOP12y ago

if the crypto library is Nacl or keyczar, then yes, maybe, but there are still a hundred ways to fuck up. If one is calling the aes function from openssh directly then no, I am bound to get it wrong.

And the whole argument about having magically independant servers that do not need to do any secure callbacks is totally blown away by the standard approach to CSRF protection - you send a nonce to the client. If it comes back to an "independant" server, the nonce still has to be looked up and confirmed. maybe you can use cycled hashes but at some point, we need to get a server make a security callback. It just has to happen to keep things simple.

j / k navigate · click thread line to collapse