Session identifier overhaul: Randomly generated session identifier

[ghost]

The session identifier model of Flask-Login presents 2 major weaknesses:

• Because Flask's Session is used for managing a user's session, if an attacker is able to get Flask's Secret Key for signing the Session cookie, he will be able to impersonate any user, as the session identifier only requires the user ID. Also, it is an unnecessary information disclosure, leaking the user ID in the cookie, which may be useful for other attacks.
• Invalidating sessions is a really complex process, as it is required to change the user's id or as it is suggested, to create an alternative user id which must be changed to a random value every time for invalidating the session.

An alternative to this approach may be using random session identifiers for each session. These random identifiers are stored in the server, so each time a user presents one, it will be able to associate it with the correct user.

With this approach, these two weaknesses are completely wiped out, as each session will have a unique session identifier and, if an attacker manages to get a session identifier, it will be unique to that user. On the other side, invalidating sessions is a really simple process, as it is only necessary to pop out these identifiers from the server storage.

This idea is indeed supported by OWASP in this cheatsheet.

I am aware that this idea presents an important overhaul to the way this extension works, but I feel like security and simplicity are more important. Maybe someone could fork this project and change the way session identifiers work.

[davidism]

Flask-Login works regardless of what session provider is used. Flask documents how to override the session provider, or Flask-Session provides multiple server side integrations. This isn't something Flask-Login itself needs to handle.

[ghost]

I wasn't aware of server side integrations of the Session object, which fixes both problems (supposing the server side integration generates a random cookie which can be revoked). Maybe we could update the docs pointing out it is important to change to a server-side implementation of the session in order to avoid both problems.

[ghost]

I would also suggest creating a config variable for setting the key name from which to retrieve the user id, as _user_id would be a very uncomfortable name choice in some other session setups (e.g column in a database). Maybe later I'll open a pull request with my suggestions.