> 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. >
That's exactly my intention, that is to extract the "essence" of session management as a possibly minimal library. Where possible I tried to base the impl on what's in Play, as I trust them to do the "right thing" (the comments in code point to pieces which are taken from Play) > *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>. > Right, maybe it would be a good idea to mandate a minimal key, or at least warn. Currently I provide a method to generate a "good", long server secret. > 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. > Well the signature is a hash, the optional encryption of the data is symmetrical. You can also trivially provide your own signature/encryption implementation by substituting one class. The sessions are meant to be verified/decrypted only on the server, but if you'd like to verify them elsewhere, then yes, you need to share the key. > 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 read about JWT, from what I understand it's kind of a combination of how header-based CSRF protection works and keeping the content of the cookie in memory only, (instead in the cookie). Also, if you want to implement "remember me", I suppose you need to resort to cookies anyway to have some kind of persistent client-side storage? > 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. > Thanks for the links! I know the basic ideas behind the auth protocols, but it's always interesting to read up some details :) I suppose adding JWT would be a good addition to the library at some point, as an alternative method of implementing sessions. Feel free to create a GH issue if you think that would be a good idea :) Adam > 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.
