Mimsy Were the Borogoves

Hacks: Articles about programming in Python, Perl, PHP, and whatever else I happen to feel like hacking at.

Per-header encryption

Jerry Stratton, November 14, 2010

In Breaking the Web’s Cookie Jar, Jeff Atwood writes about how Firesheep hacks web sessions, and then argues:

You can naively argue that every website should encrypt all their traffic all the time, but to me that’s a “boil the sea” solution. I’d rather see a better, more secure identity protocol than ye olde HTTP cookies. I don’t actually care if anyone sees the rest of my public activity on Stack Overflow; it’s hardly a secret. But gee, I sure do care if they somehow sniff out my cookie and start running around doing stuff as me! Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.

It doesn’t just seem like overkill. It is overkill. Encryption is expensive. You can say you want all traffic encrypted; you might as well say that you want all traffic slow. Servers have to do a lot of work to encrypt full web pages and every image on the page. Where I work we just installed expensive dedicated hardware to stand between the web server and the network and do nothing but encrypt all traffic.1 This is not an option for most small servers. It’s not really an option for us; all it did was move the expense from CPU usage to money usage. We could certainly put that money to good use elsewhere.

This is something that’s bugged me since I first started working with password-protected web sites over ten years ago: there is no way to encrypt just one header. Most of the time, it isn’t the web page that needs protecting. It’s the password or the session. It’s twenty to a hundred bytes out of a hundred thousand bytes or more. Jeff’s example is StackOverflow. It’s a fairly typical setup: a site with public information remembers what kind of information the visitor prefers to see, but that information is publicly available even without any login at all. The only information of any worth is the visitor’s identity; the information the visitor sees is already public.

There were a couple of half-hearted attempts to solve the problem for password-based authentication back in the nineties; the only one that survived is Digest access authentication; it is both sucky and partially unimplemented across servers and browsers.

To a large extent, cookies were just a way of pretending to be secure: pretending that the password matters rather than the identity, breaking the identity off from the password, and saying, see! Your password is safe!

Moving from password-based authentication (where the password is sent every time you view a web page) to cookie-based authentication (where a password is sent once, usually securely, and from then on a cookie is sent) never solved the issue. Passwords are only important insofar as they guard your identity. Pushing your identity into a cookie so that you can protect your password doesn’t solve anything except the tendency of people to use the same password for multiple services. Which is important, but may not matter if the cookie they steal is for your e-mail session: all they have to do is press the button that says “I forgot my password” and the other services will send a new password2 to that hacked e-mail account.

  1. Server load on the web server immediately dropped tenfold when we did this, and the server requires reboots much less often. (I’d like to say “never”, but that’s just tempting fate.)

  2. Or, worse, will send your existing password, meaning that you’ll never even know your identity was stolen.

  1. <- GeekTool and TaskPaper
  2. Autolink URLs ->