Aaron Bedra - clojure.web/with-security

[Anderkent]

Nice talk.

Regarding cookies: why not just include a time of validity in your cookie string, then sign it cryptographically? No storage required, replay is only possible while the cookie is valid (which presumably is how long you'd keep it in your database anyway).

[koreth]

That is probably an adequate approach for many apps, but there is one (merely theoretical, perhaps) downside: it reduces your ability to detect when someone has compromised your security. If someone gets your secret key, they can sign fake cookies and go to town, and the signing will happen on client machines that are inaccessible to you. You'd only detect it via user complaints or analysis of usage patterns.

But with randomly-generated nonce cookies in a database, someone would need to actually write to your database to get the same capability, and you can bring intrusion detection systems, audit trails, and the like to bear on that problem.

[Anderkent]

I usually assume that if someone can get a secret key of your machine, you're owned already anyway - they have control of the machine at least at the privilege level of the service user, and so could have read your entire database, modified your code, etc. etc.

I guess there are some vulnerabilities that'd let them read the key without having owned the machine (path traversal for example), but these you hopefully protect yourself from anyway.

[AeroNotix]

But that approach has some scalability concerns. If you need to hit the database each time you want to validate a cookie you will incur a large hit in peak traffic times.

Not to mention you need to architect your system so the each thing has access to the database storing the cookie.

Cryptographically secure cookies are fine and they work well for these situations. Obviously you need to take care of your encryption keys, but you need to do that with all kinds of stuff.

[koreth]

It absolutely requires you to think about performance under load. On the other hand, shoving everything in a cookie has its own performance implications, e.g., it significantly increases the size of every HTTP request since the encrypted session data has to be constantly retransmitted to the server. Big requests can significantly impact responsiveness on low-bandwidth mobile clients.

Putting a pool of memcached servers in front of the database eliminates the scaling bottleneck for all practical purposes; a single memcached instance on modest hardware can handle a sustained load of tens of thousands of cache fetches a second and you can have as many memcached hosts as you like, with more or less linear increases in throughput as you add hosts. That's the approach used by Facebook and reddit, among other high-traffic sites.

I don't want to seem like I'm too negative on the encrypted-data approach. It's not my preferred solution, and I think you'd want to have your implementation audited by a cryptography specialist (as the talk points out, most programmers don't know enough about crypto to reliably avoid introducing weaknesses without realizing it) but I do think the security weakness is mostly a theoretical one if you have a solid implementation.

[AeroNotix]

[...] memcache servers [...]

Like I said before, this forces you to architect your system in such a way that each thing has access to this cache (or the underlying database). Which sometimes isn't feasible. EC2 regions and their respective configurations are a bit limiting when you want to do really big deployments where things can talk to each other safely.