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

[pankajtaneja5]

Summary

This PR introduces a new Reauthentication After Risk Events section in the Authentication Cheat Sheet and adds cross-links to it from two related documents:

1. Session_Management_Cheat_Sheet.md

   • Under Session ID Life Cycle, adds a link pointing to the new reauthentication guidance.

2. Multifactor_Authentication_Cheat_Sheet.md

   • In the Adaptive or Risk-Based Authentication section, adds a link to the same reauthentication guidance.

3. Authentication_Cheat_Sheet.md

   • Adds the full Reauthentication After Risk Events section, detailing when and how to trigger reauthentication after high-risk activities (e.g., password resets, suspicious logins, account recovery).

Motivation

Developers often need to know when to require users to reauthenticate following critical security events. By:

• Centralizing best practices in the Authentication Cheat Sheet, and
• Surface-linking that section directly from session-management and MFA contexts,

we make it easy to discover and implement consistent reauthentication flows across applications.

Changes

• Authentication_Cheat_Sheet.md

  • Add new Reauthentication After Risk Events section with guidance on triggers, mechanisms, and implementation recommendations.

• Session_Management_Cheat_Sheet.md

  • Insert cross-link under Session ID Life Cycle to the new reauthentication section.

• Multifactor_Authentication_Cheat_Sheet.md

  • Insert cross-link in Adaptive or Risk-Based Authentication section to the same reauthentication section.

Next Steps

• Once merged, readers will be able to jump from session- and MFA-focused guidance straight to the detailed reauthentication best practices.
• Feedback welcome on link placement, section content, or further integrations!

You're A Rockstar

Thank you for submitting a Pull Request (PR) to the Cheat Sheet Series.

🚩 If your PR is related to grammar/typo mistakes, please double-check the file for other mistakes in order to fix all the issues in the current cheat sheet.

Please make sure that for your contribution:

• In case of a new Cheat Sheet, you have used the Cheat Sheet template.
• All the markdown files do not raise any validation policy violation, see the policy.
• All the markdown files follow these format rules.
• All your assets are stored in the assets folder.
• All the images used are in the PNG format.
• Any references to websites have been formatted as [TEXT](URL)
• You verified/tested the effectiveness of your contribution (e.g., the defensive code proposed is really an effective remediation? Please verify it works!).
• The CI build of your PR pass, see the build status here.

If your PR is related to an issue, please finish your PR text with the following line:

This PR fixes issue #1694 .

Thank you again for your contribution 😃

[kwwall]

Just ran into this and thought it would be worth mentioning here as a cautionary tale: https://tailscale.com/blog/frequent-reauth-security?lid=5wso20mx4knj

[szh]

Love this work, amazing job. LGTM!

[pankajtaneja5]

Thanks for the suggestion, @kwwall! I’ve added the Tailscale post under Additional Resources. Could you please take another look when you get a chance?

@szh can you please review again!

Also tagging @mackowski and @jmanico for review. Thanks!

[pankajtaneja5]

Hi @mackowski, thanks again for your review! I’ve removed the legacy V1 contributor entry and fixed the cross-sheet link—could you please take another look and re-approve when you have a moment?

Also, since @kwwall is on hiatus until the end of June, could someone with admin rights please dismiss the pending review request from @kwwall so we can merge as soon as we have two active approvals? Thanks everyone! 🙏

[pankajtaneja5]

Hi all—just to clarify the merge blocker:

• @kwwall’s review request is still pending. Could someone with admin rights please dismiss that review so it won’t block us?
• @mackowski, I’ve pushed the fixes you requested—would you mind re-approving when you have a moment?

Once those are cleared, we’ll have the two active approvals needed and can merge. Thanks! 🙏

[pankajtaneja5]

Hi @mackowski – just checking in on the latest changes (removed the V1 entry & fixed the cross-sheet link). Would you mind taking another look and re-approving when you have a moment?

Hi @kwwall – The legacy V1 entry has been removed and the cross-sheet link fixed. Could you please take one more look and approve when you have a moment?

[szh]

@mackowski can you please re-review?

[kwwall]

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.

[kwwall]

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.

[kwwall]

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

[kwwall]

LG(enough)TM.
P.S.- St this point, I'll bet you're sorry you asked me for a re-review. But I really should apologize, as much of this I should have mentioned the first time through.

[kwwall]

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.

[kwwall]

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.

[kwwall]

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

[kwwall]

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

[kwwall]

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.

[kwwall]

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?)

[mackowski]

lets merge it!