support encrypted sessions

[jwoudenberg]

I'm working on a so far relatively simple application that stores some sensitive data in an encrypted cookie using servant's experimental general authentication. I'd love to switch to servant-auth as Servant's new default, but am missing the functionality to encrypt session data.

One approach might be to encrypt session payloads for cookies with a HttpOnly flag by default. If the cookie is not meant to be inspected by client side code its content might as well be encrypted to hide it from malicious browser extensions and other potential attackers as well. Such an approach would not entail any loss of functionality as far as I can see, while eliminating a potential error on the side of the library user.

I'm looking forward on others' thoughts on this.

[domenkozar]

This shouldn't be hard to implement (and thus reach feature parity with servant-auth-cookie) by using JWT already standard algorithm JWE: https://hackage.haskell.org/package/jose-0.7.0.0/docs/Crypto-JOSE-JWE.html

[tmbull]

Hi, I have an application that is currently using servant-auth-cookie, but rather migrate to servant-auth since this seems to be the path forward for authentication i servant. However, I also require encrypted cookies.

@domenkozar It looks like the jose package only includes types for JWE, not the implementation (see frasertweedale/hs-jose#9). I would be comfortable implementing the servant-auth part, but implementing JWE is probably more than I have time/ability for right now as I'm not really familiar with the protocol. Is there any value in implementing a servant-auth-cookie type of encryption for cookies, or would you rather wait until hs-jose has implemented JWE?

[domenkozar]

@tmbull ah, totally missed that. You probably meant frasertweedale/hs-jose#8.

I think most of servant-auth machinery works with jose package so it's probably easier to wait, but if it would be easy to get servant-auth-cookie merged, we could start with that. I haven't looked how it's implemented though.

[tmbull]

@domenkozar You are correct. Looks like I miss-typed the issue number. My apologies.

I looked into the servant-auth-cookie implementation a little more, and it seems that they are not particularly happy with their current approach (see zohl/servant-auth-cookie#45), so I agree that it might be best to just wait for encryption in hs-jose.

[nrolland]

are there any update on this by any chance ?

[domenkozar]

Not much it seems.

[jwoudenberg]

I'd love to contribute a solution for this issue to tie us over until the jose library supports JWE. One approach I would like to try is to do encryption using saltine, which wraps Libsodium. Libsodium is a modern, opinionated set of encryption primitives providing low configurability, but easy to use secure defaults. That would reduce the risk of implementation error causing security vulnerabilities.

I'm aware that's an additional dependency though, so that's a downside. Would you open to a PR taking this direction?

[domenkozar]

@jwoudenberg do you think encryption of the JWT could be servant-auth api that servant-auth-cookie-encrypt would be one possible implementation?

[jwoudenberg]

Hey @domenkozar, I'm afraid I don't follow completely. Do you mean servant-auth-cookie-encrypt could have its own EncryptedCookie type as an alternative for the one bundled by servant-auth-server? Or to make the encryption logic servant-auth-server uses configurable?

[domenkozar]

@jwoudenberg I'm not 100% familiar with the code, but in general we want to go in direction of #151.

Ideally cookie contents should be abstracted away, while JWT+JWE being a possible implementation.

That being said, if you come up with a simpler design that makes encryption optional, I wouldn't be opposed merging it.