feat: Refined session handling

[ChristophWurst]

• Remove secondary persistent remember me tokens
• Decouple session ID and session token
• Resolves: Tried to log in "user" but could not verify token #37492

Summary

Before

Remember me is handled with persisted tokens stored in preferences. At cookie login (session expired, cookie is still alive), the token is compared with the database values, token is replaced on success. The session id is also the password/token of the session token in the password. This process is falling apart with concurrency. First, only one process can win the token race. Rarely there are two, because tokens are not read and replaced in a transaction. But then there are also two new PHP sessions and the database can only be updated once.

sequenceDiagram
    Browser->>+Server: session1, token1
    Server-->>-Browser: OK: session1, token1
    Note over Browser,Server: No activity. PHP session expires.
    Browser->>+Server: session1, token1
    Server-->>-Browser: OK: session2, token2   
    Note over Browser,Server: No activity. PHP session expires.
    par
        Browser->>+Server: session2, token2
        Server-->>-Browser: OK: session3, token3
    and
        Browser->>+Server: session2, token2
        Server-->>-Browser: ERROR: session4, logout
    end

Loading

After

Remember me is still handled by a persisted token, but the token is a random one and it doesn't change throughout the session.

sequenceDiagram
    Browser->>+Server: session1, token1
    Server-->>-Browser: OK: session1, token1    
    Note over Browser,Server: No activity. PHP session expires.
    Browser->>+Server: session1, token1
    Server-->>-Browser: OK: session2, token1   
    Note over Browser,Server: No activity. PHP session expires.
    par
        Browser->>+Server: session2, token1
        Server-->>-Browser: OK: session3, token1
    and
        Browser->>+Server: session2, token1
        Server-->>-Browser: OK: session4, token1
    end

Loading

Transition

The session id can be used as the "random" token at migration. The logic will keep that session alive as well. New sessions will use a real random token.

TODO

• Do
• Testing
• Testing
• Testing

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[kesselb]

Nice one 👍

[kesselb]

I'm a bit scared ;)
Isn't that a cyclic dependency?

[come-nc]

Would you have an overview of how this is stored in database?
This marks the end of storing login_token in preferences, right?

[Altahrim]

I have two questions on it:

• what are the security implications? By reading it (really) quickly, it seems the remember me token is valid for 15 days. If stolen, someone can use it for a long time.
• is there a possibility to lose data? In your "After" example, if data are added to session 3, they will be lost right?

[ChristophWurst]

• what are the security implications? By reading it (really) quickly, it seems the remember me token is valid for 15 days. If stolen, someone can use it for a long time.

Yes, replay attacks are possible with the current implementation.

[ChristophWurst]

Closing due to #40543 (comment). This need more time and thought.