<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Password Hashing on Nalar</title>
    <link>https://nalar.dev/tags/password-hashing/</link>
    <description>Recent content in Password Hashing on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 03 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/password-hashing/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Store Passwords with Memory-Hard Hashing</title>
      <link>https://nalar.dev/store-passwords-with-memory-hard-hashing/</link>
      <pubDate>Thu, 03 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/store-passwords-with-memory-hard-hashing/</guid>
      <description>&lt;p&gt;A login system must verify passwords, but it should not need to recover them. That distinction matters when an authentication database is copied through a vulnerability, backup exposure, or operational mistake.&lt;/p&gt;&#xA;&lt;p&gt;If the database contains plaintext passwords, the compromise immediately reveals them. If it contains fast, unsalted hashes, an attacker can test large numbers of password guesses efficiently and reuse work across accounts.&lt;/p&gt;&#xA;&lt;p&gt;Password hashing changes the problem. The application stores a &lt;strong&gt;verifier&lt;/strong&gt; produced by a deliberately expensive password-hashing function. During login, it applies the same function to the submitted password and checks whether the result matches.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
