Skip to content

Add “Reauthentication After Risk Events” section and cross-links in Authentication, Session Management, and MFA cheat sheets #1709

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.

Sign up for GitHub

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

Merged
mackowski merged 4 commits into from
Aug 1, 2025
Merged

Add “Reauthentication After Risk Events” section and cross-links in Authentication, Session Management, and MFA cheat sheets #1709

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
48c7647
Add cross-links to Reauthentication After Risk Events in Session Mana…
pankajtaneja5 Jun 20, 2025
49aedaa
Add Pankaj Taneja to CONTRIBUTOR_V1.md
pankajtaneja5 Jun 20, 2025
43a1dd3
docs: add Tailscale reauthentication UX pitfall link
pankajtaneja5 Jun 25, 2025
6768933
fix cross-sheet link
pankajtaneja5 Jun 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions cheatsheets/Authentication_Cheat_Sheet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,44 @@ The login page and all subsequent authenticated pages must be exclusively access

In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password or email address -- or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.

### Reauthentication After Risk Events

**Overview:**
Reauthentication is critical when an account has experienced high-risk activity such as account recovery, password resets, or suspicious behavior patterns. This section outlines when and how to trigger reauthentication to protect users and prevent unauthorized access. For further details, see the [Require Re-authentication for Sensitive Features](#require-re-authentication-for-sensitive-features) section.

#### When to Trigger Reauthentication

- **Suspicious Account Activity**
When unusual login patterns, IP address changes, or device enrollments occur
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That implies keeping a lot of additional metadata about authentication activity. It seems doubtful to me that most applications keep such metadata in sufficient quantity (especially for rarely used accounts) to make meaningful stochastic decisions. That's why most companies instead opt for the much easier "just email the user that their account has been accessed and from where" and consider that to sufficient. While I'm not aware of any off the top of my head (nor did I search for anything), I honestly wonder how useful things this is unless we can at least point to some decent study of a discussion of the pros and cons of what metadata should be collected and and how one determines which changes are significant when. I think this is way more subtle than most of us believe and I'm not even sure we should play the "suspicious account activity" card unless we're at least prepared to give a decent reference or two. If we want to leave this here, as-is, for now, I'm fine with that, but at the same time, an issue should be created that notes that this section needs imnprovement.

- **Account Recovery**
After users reset their passwords or change sensitive account details
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, sometimes "change sensitive account details" IS the suspicious activity. At a minimum, I'd at least want an email notification if my account had any like contact info (including beneficiaries) changed.

- **Critical Actions**
For high-risk actions like changing payment details or adding new trusted devices

#### Reauthentication Mechanisms

- **Adaptive Authentication**
Use risk-based authentication models that adapt to the user's behavior and context
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we reference any such models? It would be nice if we could.

- **Multi-Factor Authentication (MFA)**
Require an additional layer of verification for sensitive actions or events
- **Challenge-Based Verification**
Prompt users to confirm their identity with a challenge question or secondary method

#### Implementation Recommendations

- **Minimize User Friction**
Ensure that reauthentication does not disrupt the user experience unnecessarily
- **Context-Aware Decisions**
Make reauthentication decisions based on context (e.g., geolocation, device type, prior patterns)
- **Secure Session Management**
Invalidate sessions after reauthentication and rotate tokens—see the [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If multiple concurrent logins are allowed for the application, it may be more complicated than this. You may need the equivalent of Single Sign Out to do it correctly.


#### References

- [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)
- OWASP ASVS – 2.2.2: Reauthentication requirements
- NIST 800-63B: Digital Identity Guidelines – Authentication Assurance Levels

### Consider Strong Transaction Authentication

Some applications should use a second factor to check whether a user may perform sensitive operations. For more information, see the [Transaction Authorization Cheat Sheet](Transaction_Authorization_Cheat_Sheet.md).
Expand Down
2 changes: 2 additions & 0 deletions cheatsheets/Multifactor_Authentication_Cheat_Sheet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -435,6 +435,8 @@ If risk is detected, the system may:
- Enforce re-authentication
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not in scope, but elsewhere, it's been spelled "reauthentication", but spelled with a hyphen here. Personally, I prefer it with a hyphen, but even more so, I prefer consistency.

- Deny access and trigger alerting or account protection flows

For more details on when to trigger reauthentication after high-risk events—such as account recovery or suspicious activity—see the [Reauthentication After Risk Events](Authentication_Cheat_Sheet.md#reauthentication-after-risk-events) section in the Authentication Cheat Sheet
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This cross-reference is appropriate, but I still think that section needs a bit of work or some additional supporting external research.


This method is widely used in modern authentication systems to balance usability and security. However, developers must ensure that risk signals cannot be spoofed and that fallback mechanisms are not weaker than the primary MFA methods.

**Example Use Case**: A user logs in from a trusted device in a usual location — no additional prompt is needed. But if they log in from a new country using a Tor exit node, the system requires SMS verification or triggers an account lock until further verification.
Expand Down
14 changes: 14 additions & 0 deletions cheatsheets/Session_Management_Cheat_Sheet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,6 +252,20 @@ The session ID regeneration is mandatory to prevent [session fixation attacks](h

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

### Reauthentication After Risk Events

Web applications should require reauthentication after high-risk events such as:
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes, I probably would argue that just proper notification at an (existing) email address might suffice. If MFA is enabled (:crossed_fingers: ), then reauthentication after a password change makes sense, but if there's no MFA, does it really make sense to make a user re-enter the password that they've just changed after they've gone through the "forgot password" flow and just changed their password because they're working on some old system that users questions/answers? That sort of seems pointless to me. I'm not going to not approve this PR because of this, but it just seems we maybe could do a litter better here.


- Changes to critical user information (e.g., password, email address)
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend changing 'email address' to 'contact information', which would include that.

- Login attempts from new or suspicious IP addresses or devices
Copy link
Copy Markdown
Collaborator

@kwwall kwwall Jul 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd somewhat recommend to change this to state "Failed login attempts from new or suspicious IP addresses or devices". Yes, it makes sense for notifications to occur, but not (IMO), reauthentication (should be hyphenated or I'm going to have to add this to all my damned application dictionaries; sigh) if the initial authentication was successful but the device was new. (Gee, do folks never get new laptops, tablets, phones?)

- Account recovery flows (e.g., password reset or compromised-account detection)

For best practices on implementing reauthentication after these events, see the [Reauthentication After Risk Events](Authentication_Cheat_Sheet.md#reauthentication-after-risk-events) section in the Authentication Cheat Sheet

### Additional Resources

- [Why Frequent Reauthentication Can Be a UX Pitfall](https://tailscale.com/blog/frequent-reauth-security?lid=5wso20mx4knj) by Tailscale

### Considerations When Using Multiple Cookies

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.
Expand Down