6 ms·
Random question: I believe a while back Yesod did RSA encryption of client-side cookies. Is that still happening?
by shadowfiend 15y ago
Random question: I believe a while back Yesod did RSA encryption of client-side cookies. Is that still happening?
- gregwebs 15y agoYes, the default session storage is in encrypted cookies because it is convenient and good enough for many use cases. The session code is extensible though and someone has already written a Redis backend.
- shadowfiend 15y agoI'm asking because encrypting cookies seems like a pointless exercise, and seemed that way when it was first announced, as well. If you don't encrypt your entire connection, encrypting your cookie seems pointless, no?
- marshray 15y agoEncrypting and authenticating cookies allows the web app server (or server farm) to store some session state in the browser rather than hit the database for every little thing. This can have a huge positive effect on scalability.
- shadowfiend 15y agoI'm aware of the benefits of using cookies for session state, just not sure encryption itself offers serious benefits without encrypting the entire browser session via SSL. And it may offer disadvantages from an understanding standpoint, where people think the encrypted cookie provides more security than it actually does.
- Periodic 15y agoIf properly encrypted with an authenticated encryption mechanism then the server can be sure that the data has not been modified and has not been read. This would allow private data to be stored. As long as the server is the only one that knows the key, then only the server can read it. An evesdropper can still use the cookies for replay attacks, but at that point they're on the connection already. It's useful for things like storing the current user session. You wouldn't want someone to be able to log in and then change their account to someone else's by modifying the user id in their cookie. Thus this information is often stored in a server-side session. With an encrypted cookie you can push this data to the client, which makes the server stateless with respect to client sessions.
- shadowfiend 15y ago(1) Modification-prevention (the changing your account to someone else's by modifying the user id situation) is provided by the HMAC, not encryption. This is why Rails session cookies are not encrypted (as far as I know), for example. (2) If someone has your cookie, they're either already on your connection or they're on your computer. (3) The only situation where this provides any security is one in which you store data in the cookie that would not be accessible to the same user through the site. I can't think of any such data in any of my experience, but I will absolutely grant that such data may exist.
- marshray 15y ago(1) Well, he said > If properly encrypted with an authenticated encryption mechanism (2) Being on one's connection is the default assumption of the internet security model. (3) Right, the confidentiality of the site's data from the site's user may not be critical. But if done properly it does allow the site to ensure that the data it stored has not been tampered with (except perhaps to drop it or replay it). Surely this can be useful.
- snoyberg 15y agoThe clientsession package (which is what we use) both encrypts and applies a hash to the payload. Hashing prevents users from tampering with the data, and encrypting prevents inspection of the data. This means that you can even store sensitive data in a cookie without worrying if it's being compromised. (Not to say I recommend that practice, but it is possible.) There is of course some performance overhead to encrypting, but Felipe's skein package has been highly optimized, and Yesod is still able to achieve ~50,000 req/sec on modest hardware. (Apologies for not having more accurate numbers, I haven't run our benchmark suite on EC2 in over a year.)
- shadowfiend 15y agoThe content of the cookie isn't compromised, but you can trivially sidejack a cookie on an unencrypted connection and access the information through the website itself, in essence stripping any security. Arguably encrypting the cookie is a waste of processor time, but more importantly I think you may be giving people a false sense of security. The proper way to do secure interactions is via SSL, and I'm not sure encrypted cookies vs simply HMACed cookies gives you any true security advantage (as session storage or anything else).
- gregwebs 15y agoSSL is (important as you say but) orthogonal to this issue. If you steal a non-encrypted cookie and take over a user's session the result is the same.
- shadowfiend 15y agoYes, that's precisely what I'm saying. So, let me put it differently: what security advantage does an encrypted session cookie confer? I see two possibilities: - Someone who hijacks a request with the cookie in it cannot see the data in the cookie. But they can access the site as the user, so there is no real world benefit to this fact. - Someone on the same computer cannot see the data in the cookie. But again, they have the cookie value, so they can access the site as the user, so there is again no real world benefit to the fact that they can't see the data in the cookie itself, because they can interact with the site and see the data there. I guess I'm just looking for an example scenario where the cookie being encrypted offers a concrete benefit from a security standpoint.