[GH-ISSUE #188] "Stay logged in" option #155

Closed
opened 2026-02-25 21:34:18 +03:00 by kerem · 12 comments
Owner

Originally created by @szilardx on GitHub (Apr 20, 2017).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/188

Originally assigned to: @jasonmunro on GitHub.

I use Cypht as a desktop mail replacement, and I am really satisfied with it! (Also happy to see the desktop notification commits :) )

My question is: how the login sessions - cookies work? Now I set the session management to database based session, hoping these logins would last longer.

Would it be possible, to remain logged in for longer periods? Even if the browser is closed, ip changed, and even if logged in from multiple locations (mobile and desktop, etc)

Thanks!

Originally created by @szilardx on GitHub (Apr 20, 2017). Original GitHub issue: https://github.com/cypht-org/cypht/issues/188 Originally assigned to: @jasonmunro on GitHub. I use Cypht as a desktop mail replacement, and I am really satisfied with it! (Also happy to see the desktop notification commits :) ) My question is: how the login sessions - cookies work? Now I set the session management to database based session, hoping these logins would last longer. Would it be possible, to remain logged in for longer periods? Even if the browser is closed, ip changed, and even if logged in from multiple locations (mobile and desktop, etc) Thanks!
kerem 2026-02-25 21:34:18 +03:00
Author
Owner

@jasonmunro commented on GitHub (Apr 20, 2017):

Thanks for the suggestion. Login sessions do not expire, however there are a number of conditions that cause them to end:

  • session cookies are "session only", so closing the browser deletes them, which logs you out (local storage is session only as well, however clearing it does not log you out, it simply starts rebuilding with new request results).
  • we use a "session fingerprint" to mitigate session hijacking attacks. We hash a number of HTTP headers that should not change during a login session, and the client remote ip is part of that hash.
  • There is no explicit expiration time to a session, it could last forever if the above conditions are not triggered.
  • Simultaneous multiple logins should not effect each other, so that aspect of the session process is not relevant to how long you stay logged in.
  • The session backend should not matter either, unless it has some explicit server side lifetime enforcement, or in the case of memcache, if that process is restarted.

With all that said, it should be possible to create a module set to add a "stay logged in" option. It would disable the ip check in the fingerprint code, and change the cookie lifetimes to not be "session only". The relevant parts of this code are not something that can be done directly from a module set yet, so I will need to abstract some things in order to make it possible to do cleanly.

<!-- gh-comment-id:295939896 --> @jasonmunro commented on GitHub (Apr 20, 2017): Thanks for the suggestion. Login sessions do not expire, however there are a number of conditions that cause them to end: - session cookies are "session only", so closing the browser deletes them, which logs you out (local storage is session only as well, however clearing it does not log you out, it simply starts rebuilding with new request results). - we use a "session fingerprint" to mitigate session hijacking attacks. We hash a number of HTTP headers that should not change during a login session, and the client remote ip is part of that hash. - There is no explicit expiration time to a session, it could last forever if the above conditions are not triggered. - Simultaneous multiple logins should not effect each other, so that aspect of the session process is not relevant to how long you stay logged in. - The session backend should not matter either, unless it has some explicit server side lifetime enforcement, or in the case of memcache, if that process is restarted. With all that said, it should be possible to create a module set to add a "stay logged in" option. It would disable the ip check in the fingerprint code, and change the cookie lifetimes to not be "session only". The relevant parts of this code are not something that can be done directly from a module set yet, so I will need to abstract some things in order to make it possible to do cleanly.
Author
Owner

@szilardx commented on GitHub (Apr 20, 2017):

Thank you for the quick response!

An idea: if it is possible it would be good to set an expiration timeframe for the sessions ie: 2 days. If the user interacts with the server, then the cookie could be updated. So if I open the Cypht every second day in the same browser, I would remain logged in "forever".

<!-- gh-comment-id:295944346 --> @szilardx commented on GitHub (Apr 20, 2017): Thank you for the quick response! An idea: if it is possible it would be good to set an expiration timeframe for the sessions ie: 2 days. If the user interacts with the server, then the cookie could be updated. So if I open the Cypht every second day in the same browser, I would remain logged in "forever".
Author
Owner

@dumblob commented on GitHub (Apr 21, 2017):

With all that said, it should be possible to create a module set to add a "stay logged in" option.

Then this module should definitely put an overly big red warning "THIS DISABLES A PROTECTION AGAINST IP HIJACKING AND WEB BROWSER DATA REUSE" to the "stay logged in" option.

<!-- gh-comment-id:296150004 --> @dumblob commented on GitHub (Apr 21, 2017): >With all that said, it should be possible to create a module set to add a "stay logged in" option. Then this module should definitely put an overly big red warning "THIS DISABLES A PROTECTION AGAINST IP HIJACKING AND WEB BROWSER DATA REUSE" to the "stay logged in" option.
Author
Owner

@szilardx commented on GitHub (Apr 26, 2017):

Yes, it raises some security concern, but I rather chose this than saving my password in my browser. (Because for example the cookie should expire, but the browser will have the password forever?)

<!-- gh-comment-id:297390073 --> @szilardx commented on GitHub (Apr 26, 2017): Yes, it raises some security concern, but I rather chose this than saving my password in my browser. (Because for example the cookie should expire, but the browser will have the password forever?)
Author
Owner

@jasonmunro commented on GitHub (Jul 3, 2017):

After several failed attempts at getting this done, I finally added support for this. I chose to build this into the core module set rather than create a new one just for this purpose. Here is how it works:

There are 2 new settings for the hm3.ini file:

allow_long_session (defaults to false)
long_session_lifetime (defaults to 30 days)

With allow_long_session set to true, users will have a "stay logged in" option when logging in. The session lifetime is determined by the long_session_lifetime setting. If users don't check the box, everything behaves the same as it does now. If they do, the session lifetime is extended, and the remote IP check is disabled, though other browser attributes are still used to create the "fingerprint". The hm3.ini settings comment contains an all caps warning: " USE WITH CAUTION SINCE THIS DISABLES SOME SESSION PROTECTIONS"

Seems to be working here, though I have not done a ton of testing yet. Let me know if you run into any trouble, and thanks for the feedback!

<!-- gh-comment-id:312697478 --> @jasonmunro commented on GitHub (Jul 3, 2017): After several failed attempts at getting this done, I finally added support for this. I chose to build this into the core module set rather than create a new one just for this purpose. Here is how it works: There are 2 new settings for the hm3.ini file: allow_long_session (defaults to false) long_session_lifetime (defaults to 30 days) With allow_long_session set to true, users will have a "stay logged in" option when logging in. The session lifetime is determined by the long_session_lifetime setting. If users don't check the box, everything behaves the same as it does now. If they do, the session lifetime is extended, and the remote IP check is disabled, though other browser attributes are still used to create the "fingerprint". The hm3.ini settings comment contains an all caps warning: " USE WITH CAUTION SINCE THIS DISABLES SOME SESSION PROTECTIONS" Seems to be working here, though I have not done a ton of testing yet. Let me know if you run into any trouble, and thanks for the feedback!
Author
Owner

@szilardx commented on GitHub (Jul 4, 2017):

Thank you very much! 👍 It works perfectly so far!
I'll report on long term trouble, if there are any.

<!-- gh-comment-id:312863585 --> @szilardx commented on GitHub (Jul 4, 2017): Thank you very much! 👍 It works perfectly so far! I'll report on long term trouble, if there are any.
Author
Owner

@dumblob commented on GitHub (Jul 9, 2017):

USE WITH CAUTION SINCE THIS DISABLES SOME SESSION PROTECTIONS

Could you add a few examples of the disabled protections in paretheses? In the end it could look like:

USE WITH CAUTION SINCE THIS DISABLES SOME SESSION PROTECTIONS (CLIENT IP CHECK, CLIENT DATA REUSE, ...)

By the way speaking about IP checking - how exactly will it cope with MPTCP (i.e. multiple client IPs in one TCP connection)?

<!-- gh-comment-id:313968536 --> @dumblob commented on GitHub (Jul 9, 2017): > USE WITH CAUTION SINCE THIS DISABLES SOME SESSION PROTECTIONS Could you add a few examples of the disabled protections in paretheses? In the end it could look like: `USE WITH CAUTION SINCE THIS DISABLES SOME SESSION PROTECTIONS (CLIENT IP CHECK, CLIENT DATA REUSE, ...)` By the way speaking about IP checking - how exactly will it cope with MPTCP (i.e. multiple client IPs in one TCP connection)?
Author
Owner

@jasonmunro commented on GitHub (Jul 10, 2017):

Added some more details to the ini file here: github.com/jasonmunro/cypht@5f621a9e80

No idea how MPTCP might cause problems with Cypht - but if it results in various remote IP addresses being seen by the server - it would definitely log you out frequently :)

<!-- gh-comment-id:314275274 --> @jasonmunro commented on GitHub (Jul 10, 2017): Added some more details to the ini file here: https://github.com/jasonmunro/cypht/commit/5f621a9e80de6fec70bf79488aca350ed6a8fce3 No idea how MPTCP might cause problems with Cypht - but if it results in various remote IP addresses being seen by the server - it would definitely log you out frequently :)
Author
Owner

@dumblob commented on GitHub (Jul 12, 2017):

No idea how MPTCP might cause problems with Cypht - but if it results in various remote IP addresses being seen by the server - it would definitely log you out frequently :)

Yes, that's exactly it 😢. See ftp://ftp.fu-berlin.de/doc/rfc/authors/rfc6897.xml#rfc.section.3.2.2 and ftp://ftp.fu-berlin.de/doc/rfc/authors/rfc6897.xml#sec_query_addr (IPs may be added and removed dynamically very often) and ftp://ftp.fu-berlin.de/doc/rfc/authors/rfc6897.xml#sec_basic_sockets (new API supporting the dynamics of addition and removal of subflows).

I can't see any good way how to check IPs. It seems with MPTCP any such additional security measure on 1.-4. (inclusive) layer of the OSI model will need to be disabled 😢.

<!-- gh-comment-id:314903198 --> @dumblob commented on GitHub (Jul 12, 2017): >No idea how MPTCP might cause problems with Cypht - but if it results in various remote IP addresses being seen by the server - it would definitely log you out frequently :) Yes, that's exactly it :cry:. See ftp://ftp.fu-berlin.de/doc/rfc/authors/rfc6897.xml#rfc.section.3.2.2 and ftp://ftp.fu-berlin.de/doc/rfc/authors/rfc6897.xml#sec_query_addr (IPs may be added and removed dynamically very often) and ftp://ftp.fu-berlin.de/doc/rfc/authors/rfc6897.xml#sec_basic_sockets (new API supporting the dynamics of addition and removal of subflows). I can't see any good way how to check IPs. It seems with MPTCP any such additional security measure on 1.-4. (inclusive) layer of the [OSI model](https://en.wikipedia.org/wiki/OSI_model ) will need to be disabled :cry:.
Author
Owner

@jasonmunro commented on GitHub (Jul 13, 2017):

The IP check has dubious value in "fingerprinting". there are obvious cases where it is a bit overkill anyway (just got home, my phone hops on wifi, I'm logged out). I think I will keep it since it does represent a potential shield from session hijacking for those who want it, but add an ini option to disable it.

<!-- gh-comment-id:315216034 --> @jasonmunro commented on GitHub (Jul 13, 2017): The IP check has dubious value in "fingerprinting". there are obvious cases where it is a bit overkill anyway (just got home, my phone hops on wifi, I'm logged out). I think I will keep it since it does represent a potential shield from session hijacking for those who want it, but add an ini option to disable it.
Author
Owner

@jasonmunro commented on GitHub (Jul 14, 2017):

@dumblob I added an option to disable the client ip check here: github.com/jasonmunro/cypht@2108e8364c

<!-- gh-comment-id:315418135 --> @jasonmunro commented on GitHub (Jul 14, 2017): @dumblob I added an option to disable the client ip check here: https://github.com/jasonmunro/cypht/commit/2108e8364cfca17dbc336f29ee2bad9606d37cf7
Author
Owner

@dumblob commented on GitHub (Jul 16, 2017):

@jasonmunro perfect, thank you! Let me propose a tiny addition - namely a notion about MPTCP (MultiPath TCP) (both MPTCP and MultiPath TCP shall be present, because both are very common when searching for this technology) in the comment of the disable_ip_check option.

<!-- gh-comment-id:315620871 --> @dumblob commented on GitHub (Jul 16, 2017): @jasonmunro perfect, thank you! Let me propose a tiny addition - namely a notion about `MPTCP (MultiPath TCP)` (both `MPTCP` and `MultiPath TCP` shall be present, because both are very common when searching for this technology) in the comment of the `disable_ip_check` option.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/cypht#155
No description provided.