Changing password should invalidate all other sessions

Created on 18 June 2015, over 9 years ago
Updated 22 February 2024, 10 months ago

Follow-up to #2508627: Changing email address should invalidate one-time login links

Problem/Motivation

Assume I realize I left myself logged into a shared computer to my Drupal site account.

I change my password to protect myself.

However, the session on the shared computer is NOT invalidated and anyone with access to that machine continues to have access to my Drupal site account.

Proposed resolution

Add to the session API a method that allows invalidating all sessions based on username or uid.

Beta phase evaluation

<!--Uncomment the relevant rows for the issue. -->

Remaining tasks

  • Add a method to \Drupal\Core\Session\SessionManager\SessionManager, similar to \Drupal\Core\Session\SessionManager\SessionManager::delete(), that deletes all sessions EXCEPT the current one — suggested ::deleteOther() — see patch in #13.
  • Write tests
  • Review and RTBC.

User interface changes

n/a

API changes

API addition

Need to expand the session API to support invalidating all sessions for a user, and make that an API back-ends need to support in some way.

Because of that requirement for back-ends to support it, this is not something that can readily be added in 8.1.x so must be added to 8.0.x

Data model changes

None

For drupal 7 there are contrib solutions that work only for SQL session storage: https://www.drupal.org/node/2294061

original report was part of the Drupal 8 bug bounty
https://tracker.bugcrowd.com/submissions/39a728dfa89b4029bbc15499c410b97...
https://tracker.bugcrowd.com/submissions/756a3dbf67e9f3e917f4525c0ef9c35...

🐛 Bug report
Status

Fixed

Version

10.0

Component
User system 

Last updated about 15 hours ago

Created by

🇺🇸United States pwolanin

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024