Hi You have something similar in concept to what Play Framework uses for sessions today. Nothing wrong with that per say, but writing secure protocols (session serialization and shared trust) is hard for non trivial implementations.
*For example:* The security effect of the Hmac SHA-1 that you are using is a function of the key size (5.3.4 Security Effect of the HMAC Key <http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf>) the user chooses. But you do not mandate what the minimal length is in your implementation. Even with a larger key, using Hmac SHA-256 instead, with a minimal key size of 256 bits is a safer bet <http://tools.ietf.org/html/rfc7518#section-3.2>. Your implementation, like Play Framework, limits the signature to a symmetrical pre shared secret (HMAC and AES). This is effective for basic scenarios but limiting if you'd wish to not trust all services that consumes the session, since anyone verifying the session needs your secret and is therefore able to modify the session. Without steering you off your current path, I just wish to mention JWT (Json Web Token) which is a token forma <http://jwt.io>t typically sent as a OAuth2 Bearer Token (using the HTTP Authorization header). JWT has security considerations as well as a client side singed session (claims) addressed in a standardized way with support for both symmetrical and asymmetrical signature and encryptions. I'm not suggesting that you abandon your current path but reading the standards around OpenID Connect <http://openid.net/connect/> might be a source of inspiration as they are well written and talk about many subtle security considerations (scroll down and look at the underpinnings group, read about JWA, JWK, JWS, JWE, JWT) If you do want to use JWT then know that implementing all of JWT (or OpenID Connect for that matter) from scratch is quite a task, but there are well written and easy to use libraries such as Jose4j <https://bitbucket.org/b_c/jose4j/wiki/Home> available. One caveat is that the client needs to add the JWT itself to a header, that implies a web page where you call APIs via javascript. Good luck going forwards! Libraries like these are very useful. /Magnus Den fredag 10 juli 2015 kl. 16:41:17 UTC+2 skrev Adam Warski: > > Hello, > > I started recently working on a small side-project containing akka-http > directives to handle client-side sessions, csrf protection and remember-me. > The motivation is to fill in the missing piece necessary to use akka-http > as a backend for SPA webapp. > > I'd like things to be quite secure, hence: > > * the sessions are signed, optionally encrypted and with an optional > expiry date > * csrf uses headers as the preferred method of submitting the token (in > addition to a cookie) > * remember-me hashes tokens, uses selectors in addition to tokens > > Sessions are typed, so it's quite easy to store a simple case class > (client-side). > > Here's the github repo: https://github.com/softwaremill/akka-http-session > which also contains a very-very simply example app: > > https://github.com/softwaremill/akka-http-session/blob/master/example/src/main/scala/com/softwaremill/example/Example.scala > > The project is just over a week old, so code reviews / comments / etc. > more than welcome :) > > Adam > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
