-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement cookie-based sessions #10
Conversation
On second thought: I believe this should be in a separate library. This way, users will have to explicitely choose to use cookie-based sessions and are more likely to read the security implications they have. |
|
This pull request adds a cookie-based session implementation to this library. Cookie-based sessions require no serverside storage and thus scale very well.
Usage
Inside the routing setup:
A binary-safe 32 byte secret key can be generated using the following:
Security
As stated here:
Though the same applies for server-side sessions with session IDs transmitted via cookies, we can destroy the attached session on the server-side to invalidate in these cases, e.g. by deleting the session file or removing the relevant row from the database. For cookie-based sessions, there is no way to remotely guarantee session destruction - and thus no way for a safe user-based "Log me off on all devices" functionality.
However, if we use cookie-based sessions to store short-lived access tokens, we can reduce this risk significantly: A replay can only occur during that window of time. For Microsoft 365, this time is roughly one hour.
👉 Long story short: If there's an easy possibility to use server-side sessions, do that. If dependencies come at a high cost and you have ways of managing the risk, or for development purposes, this implementation can be a valid choice.
Internals
The session data is encrypted in the cookie and then encoded in base64 to use 7 bit only. The first byte controls the algorithm used:
S
for Sodium, using sodium_crypto_box_open(), requires Sodium extensionO
for OpenSSL, using openssl_encrypt(), requires OpenSSL extensionThe encrypted value is signed by a hash to detect any bit flipping attacks.
Compression
To prevent hitting the browser cookie limits too early, the cookie values are compressed using LZW (which is relatively easy to implement and gives good savings without requiring an extra PHP extension compiled in) if it's deemed worthwhile. If the cookie value is compressed, the indicators above appear in lowercase (
s
ando
instead ofS
andO
).An example:
https://api.twitter.com/1.1/account/verify_credentials.json
): 2814 bytesSee also
https://github.com/SaintFlipper/EncryptedSession
https://blog.miguelgrinberg.com/post/how-secure-is-the-flask-user-session