<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Authentication on Nalar</title>
    <link>https://nalar.dev/tags/authentication/</link>
    <description>Recent content in Authentication on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 02 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/authentication/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Design Secure Password Reset Flows</title>
      <link>https://nalar.dev/design-secure-password-reset-flows/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/design-secure-password-reset-flows/</guid>
      <description>&lt;p&gt;Password reset is an authentication mechanism. Anyone who can complete the reset flow can usually take control of the account, so recovery deserves protections comparable to login.&lt;/p&gt;&#xA;&lt;p&gt;A secure design must prevent token guessing, account enumeration, replay, accidental disclosure, and long-lived takeover opportunities.&lt;/p&gt;&#xA;&lt;h2 id=&#34;return-the-same-public-response&#34;&gt;Return the same public response&lt;/h2&gt;&#xA;&lt;p&gt;A reset form often accepts an email address or username. Do not reveal whether that identifier exists.&lt;/p&gt;&#xA;&lt;p&gt;Prefer a response such as:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Prevent Session Fixation During Web Authentication</title>
      <link>https://nalar.dev/prevent-session-fixation-web-authentication/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/prevent-session-fixation-web-authentication/</guid>
      <description>&lt;p&gt;Session fixation occurs when an attacker can cause a victim to authenticate while using a session identifier the attacker already knows. If the application keeps that identifier after login, the attacker may reuse it to access the newly authenticated session.&lt;/p&gt;&#xA;&lt;p&gt;The core defense is to change the session identifier whenever privilege changes.&lt;/p&gt;&#xA;&lt;h2 id=&#34;rotate-at-authentication-boundaries&#34;&gt;Rotate at authentication boundaries&lt;/h2&gt;&#xA;&lt;p&gt;After credentials, passkeys, or another authentication factor succeeds, create a fresh unpredictable session identifier and retire the pre-authentication identifier. Apply the same principle after privilege elevation, impersonation boundaries, or other security-sensitive identity changes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
