Make session auth depend on more than the static user_id for independent invalidation

[LostKobrakai]

Invalidating active phoenix sessions in case any do get compromised does require changing the session secret, a.k.a. dropping all active sessions. A more secure way would be to add some kind of db backed session key to the session, which can be reset/changed independently per user.

Some of this could already be changed with phauxth by using custom implementations, but it seems the assumption of the session holding a current_user key with the user_id is hardcoded into the project.

Is this something you would consider adding? I might even send a PR, because otherwise your library seems really nice.

See here: https://youtu.be/w3lKmFsmlvQ?t=24m9s https://elixirforum.com/t/33-elixirconf-2017-plugging-the-security-holes-in-your-phoenix-application/8565/21

[riverrun]

I'm researching this at the moment.

These are my current thoughts on the matter:

• add a sessions (array or map) column to the user database table, which would contain session identifiers
• the format of the session_id would be a concatenation of user_id, timestamp and random value
  • possibly add the timestamp to the database table rather than be in the session_id
• the check_session function would get the session_id from the session, parse the session_id to get the user_id and check that the session_id is still valid

These ideas are open for discussion, so I welcome feedback, and it would be nice to see more examples of how other libraries (in other languages) handle this.

[riverrun]

The new_sessions branch shows a draft implementation of using a session_id instead of user_id for session authentication.

Notes about the implementation

• the sessions column in the database would be a map - with session_ids as keys and timestamps as values
  • the timestamps can be used to tell if the session has expired
• the session_id format is a concatenation of one byte 'freshness' ("F" or "S" [fresh or stale login]), 16-byte random string and user_id
  • current user information is still accessed by calling Accounts.get(user_id)

Feedback welcome.

[LostKobrakai]

Having the session store be a map seems to be a good idea. I'd just rather have asession_context.get_sessions(user) call instead of %{sessions: sessions} = user_context.get_user(user_id). This can easily accomplish the same, but is far more extendable. E.g. storing the user in the db, but the session_keys in ets/redis/mnesia.

After a bit more thinking about it this really feels like reinventing what Plug.Session.Store is supposed to be. So this really seems like a nice and simple solution for not really running with a full server side session store.

[LostKobrakai]

Seems like mozilla did something similar with persona: https://hacks.mozilla.org/2012/12/using-secure-client-side-sessions-to-build-simple-and-scalable-node-js-applications-a-node-js-holiday-season-part-3/

[riverrun]

The phauxth-example v1.2 branch provides an example of using the new_sessions branch.

[LostKobrakai]

I feel like the session key generation could be part of the login flow, like Login.add_session(conn, user).

[riverrun]

I've moved it to the Login.Base module, so it will be part of any module that uses Login.Base.

[riverrun]

I released version 1.2, with the new session management, yesterday.

I have added information about upgrading and the new session implementation to the wiki.

[LostKobrakai]

Looks good. Will try to merge it into my custom stuff and see how it goes.