PulsePost-mortem: sessions not being signed out
The background to, and response to, an event in which leavers' sessions did not expire.
This is a template for publishing a security event. Where an event is found to have affected users, UNCHAIN, Inc. publishes the background, what was done and who was affected, and thanks whoever reported it. When publishing an actual event, we use this structure: summary, how it arose, what we did, who was affected, preventing recurrence, acknowledgements, further reading. What follows is a worked example. Dates, reporter names, numbers of people and items, and version numbers are left as placeholders, to be replaced with the real values on publication. Where a third-party supplier is named, agree it with them before publishing.
Summary
For users signed in with an account from an external identity platform, the Pulse session did not expire automatically after that account was suspended or deleted. The users concerned could carry on viewing the past meeting notes and transcripts stored in Pulse until they explicitly signed out themselves.
Following a report from an external researcher, we investigated and applied fixes to both the desktop app and the web app.
| Item | Details |
|---|---|
| Affected | Members of a workspace who signed in with an account from an external identity platform |
| Number affected | [number of users affected] |
| Date reported | Please contact us |
| Reported by | [reporter name] ([reporter's organisation]) |
| Desktop app fixed | Please contact us |
| Web app fixed | Please contact us |
| Action needed by users | None (those affected have been signed out automatically) |
How it arose
This event arose because the validity of a Pulse session was not tied to the state of the linked external account. The direct cause was that validity was only checked at the moment of sign-in.
Background
| Date | What happened |
|---|---|
| Please contact us | Workspaces are launched |
| Please contact us | A researcher reports that the session persists where a user unlinks the external identity platform |
| Please contact us | We acknowledge the report and begin an internal investigation |
| Please contact us | During the investigation we confirm the same thing happens not only on unlinking, but also when an account is suspended or deleted |
| Please contact us | The desktop app fix is released |
| Please contact us | The web app fix is applied |
| Please contact us | The internal investigation concludes and this post-mortem is published |
Direct cause
A Pulse session was not tied to the validity of the linked external account. Once authentication had taken place at the external identity platform and a token had been received, the session remained valid until the user signed out themselves, even if the account was later suspended or deleted.
Validity was checked only at sign-in; it was not part of the session refresh. Where an organisation suspended a leaver's account, that fact went on not being reflected in the session on Pulse's side.
What we did
| Date | What was done |
|---|---|
| Please contact us | Received the report and reproduced the behaviour |
| Please contact us | Confirmed that users with a suspended or deleted account could still reach Pulse |
| Please contact us | Identified the users affected ([number of users affected] who were members of a workspace) |
| Please contact us | Implemented automatic sign-out where the link to the external account becomes invalid |
| Please contact us | Released the fix to the desktop app |
| Please contact us | Applied a further fix to the web app |
Who was affected
- Those affected are the [number of users affected] people who, since workspaces launched, unlinked their external account or had that account suspended or deleted, and who were members of a workspace.
- What those users could see was limited to the meeting notes and transcripts they already had permission to view. This was not an event in which anyone could reach other users' notes without permission.
- All the users affected were signed out automatically when the fix was applied.
- No action is needed by users.
An event of this kind affects how reliably a leaver's access is revoked. Suspending an account on the identity platform does not necessarily expire the session on a connected service immediately. We recommend that your leaver procedure include explicitly removing access on each service. For how to remove a member from a workspace, see Workspaces.
Where personal data is leaked, lost or damaged, or there is a risk of that, the nature of the case may make it necessary to report to the Personal Information Protection Commission under Article 26 of the Act on the Protection of Personal Information (a preliminary and a final report) and to notify the individuals concerned. The situations that must be reported are set out in Article 7 of the Enforcement Rules, the reporting deadlines in Article 8, and what must be notified to individuals in Article 10. In this worked example, what could be seen was limited to information the user already had permission for, so we treat it as not amounting to a leak of personal data. For an actual event, decide this after establishing the scope of permissions and whether access actually occurred.
This page is published as something UNCHAIN, Inc. does of its own accord. No law generally requires private businesses to publish security events. The obligations that can arise in law are reporting to the Personal Information Protection Commission and notifying individuals under Article 26 of the Act on the Protection of Personal Information; reporting a leak of the secrecy of communications where registered as a telecommunications carrier; and notification under contracts with corporate customers.
Preventing recurrence
- Verification on token refresh — we added a step checking the validity of the linked account to the access token refresh. The check previously made only at sign-in now also happens while a session continues.
- Periodic checks — we are adding a mechanism that checks the state of linked accounts periodically, so that suspension and deletion are detected sooner.
- A review across authentication — we have begun a product-wide review of authentication and session management.
- Review of changes — we have established a procedure requiring prior review of any change that affects authentication.
Acknowledgements
Our thanks to [reporter name] ([reporter's organisation]) for their responsible disclosure. Because the report was specific, we were able to establish early on that the impact went beyond what was originally reported.
Further reading
- Vulnerability disclosure policy — the scope of permitted research, how to report, and how we respond to reporters
- Workspaces — adding and removing members, and managing permissions
- Our security arrangements — the technical and organisational safeguards in place day to day
- Enquiries about this matter: tharada@the-unchain.com / vulnerability reports: tharada@the-unchain.com
Where the reporter or an external researcher has published technical information, link to it here. Agree with whoever published it whether and when to include it.