🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🔑 धडा 04 — Authentication: तुम्ही कोण आहात हे सिद्ध करणे

📍 तुम्ही इथे आहात: 16 पैकी धडा 04 · मागे: lesson-03-browser-server · पुढे: lesson-05-oauth-oidc

📦 या ब्रँचमध्ये काय आहे

धडे 01–03, आणि ओळखपत्र खिडकीचा पहिला धडा. शाळेने असे काहीतरी साठवले पाहिजे ज्याने ती password तपासू शकेल password न साठवता. तुम्ही password ला salt आणि हळू key-derivation function (PBKDF2) ने hash करता, बरोबर आणि चुकीचे login तपासता, आणि चोरलेला hash किती वेगाने ओळखता येतो त्याची तुलना करता. मग MFA, passkeys, आणि sessions विरुद्ध tokens. sec/demo.py मधले passwords() हे दाखवते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

ओळखपत्र खिडकीला दररोज सकाळी कतरिनाचा गुप्त शब्द तपासावा लागतो. पण तिने तो शब्द कधीही लिहून ठेवता कामा नये — चोर वही चोरू शकतो.

म्हणून खिडकी एक हुशार गोष्ट करते. ती कतरिनाचा शब्द घेते, फक्त तिच्यासाठीचे एक random sticker जोडते (salt), आणि दोन्ही एका खूप हळू दळणाऱ्या यंत्रात घालते. यंत्र handle 200,000 वेळा फिरवते आणि एक डाग देते. खिडकी sticker आणि डाग लिहून ठेवते.

उद्या कतरिना पुन्हा तिचा शब्द सांगते. खिडकी तिचे sticker जोडते, पुन्हा दळते, आणि डागांची तुलना करते. तोच डाग → तोच शब्द.

वही चोरणाऱ्या चोराला फक्त stickers आणि डाग दिसतात. शब्द शोधण्यासाठी त्याला अंदाज करावा लागतो, 200,000 वेळा दळावे लागते, तुलना करावी लागते — प्रत्येक अंदाजासाठी, प्रत्येक विद्यार्थ्यासाठी, कारण प्रत्येकाचे sticker वेगळे असते. हे मुद्दामच हळू आहे.

आणि महत्त्वाच्या दारांसाठी खिडकी दुसरी गोष्टही मागते — कतरिनाच्या phone वरचा code, किंवा तिची passkey. फक्त चोरलेला शब्द पुरेसा नसतो.

🗺️ आकृती

flowchart LR
    pw["🔤 password"] --> kdf["🐢 slow KDF<br/>PBKDF2-SHA256 × 200,000<br/>(Argon2id in production)"]
    salt["🎲 random salt<br/>16 bytes, per user"] --> kdf
    kdf --> store["📒 stored: salt + iterations + hash<br/>never the password"]
    login["🔤 login attempt"] --> kdf2["🐢 same KDF, same salt"]
    store --> kdf2
    kdf2 --> cmp{"constant-time<br/>compare"}
    cmp -->|"match"| mfa["📱 second factor<br/>TOTP · passkey"]
    mfa --> sess["🍪 new session id"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l04

❓ काय

Authentication — तुम्ही कोण आहात हे सिद्ध करणे. (Authorization — तुम्ही काय करू शकता — हा धडा 06 आहे.) इथल्या चुका म्हणजे A07:2021 – Identification and Authentication Failures.
Passwords कधीही साठवू नका — साध्या text मध्ये नाही, encrypted नाही (key leak होऊ शकते), जलद hash (MD5, SHA-256) ने सुद्धा नाही.
Salt — random bytes, प्रत्येक user साठी वेगळे, hash च्या शेजारी साठवलेले. एकच password असलेल्या दोन users ना वेगवेगळे hashes मिळतात, आणि चोर सगळ्यांसाठी आधीच गणन केलेली एक table वापरू शकत नाही.
हळू key-derivation function (KDF) — मुद्दाम महाग बनवलेला hash, ज्याचा work factor तुम्ही काळानुसार वाढवू शकता. OWASP ची Password Storage Cheat Sheet (2023) शिफारस करते:
- सर्वप्रथम Argon2id (किमान 19 MiB memory, 2 iterations, 1 degree of parallelism),
- Argon2id उपलब्ध नसेल तर scrypt,
- जुन्या systems साठी bcrypt (work factor 10 किंवा जास्त; तो फक्त पहिले 72 bytes वाचतो),
- FIPS-140 मान्यता आवश्यक असेल तेव्हा 600,000 किंवा जास्त iterations सह PBKDF2-HMAC-SHA256. Lab 200,000 iterations सह PBKDF2 वापरते ते फक्त demo जलद चालावा म्हणून — खऱ्या systems मध्ये वरचे आकडे वापरा.
Constant-time compare — पहिला byte वेगळा असो की शेवटचा, hmac.compare_digest ला तेवढाच वेळ लागतो, त्यामुळे timing मधून काहीच उघड होत नाही.
MFA (multi-factor authentication) — तुम्हाला माहीत असलेली गोष्ट + तुमच्याकडे असलेली गोष्ट (TOTP app, security key) किंवा तुम्ही स्वतः. Passkeys (WebAuthn / FIDO2) password ऐवजी device वरची key pair वापरतात; private key कधीच device सोडत नाही, आणि ती फक्त खऱ्या site लाच उत्तर देते, त्यामुळे तिचे phishing होऊ शकत नाही.
Login चे इतर बचाव — back-off सह rate limits आणि lock-outs, नवे passwords breached passwords च्या यादीशी तपासणे, आणि सर्वसाधारण error messages ("चुकीचा email किंवा password").
Sessions विरुद्ध tokens — login नंतर server एकतर HttpOnly cookie मध्ये random session id देतो (server state ठेवतो; revoke करणे सोपे) किंवा JWT सारखा signed token (state त्याच्या आतच असते; expire होण्याआधी revoke करणे कठीण). Login वेळी नवा session id द्या, म्हणजे login आधी घुसवलेला id निरुपयोगी ठरतो.

🤔 का

कारण password databases leak होतात — SQL injection (धडा 01), हरवलेला backup, किंवा निष्काळजी log मधून. ते leak झाले की चोर आणि तुमच्या users ची accounts — आणि त्यांनी password पुन्हा वापरलेल्या इतर सगळ्या sites — यांच्यामध्ये फक्त hash किती हळू आहे एवढेच उरते. GPU वर जलद hash चे सेकंदाला अब्जावधी अंदाज होतात. हळू, salted hash चे फक्त हजारो. MFA आणि passkeys मुळे ओळखलेला password एकटा पुरेसा ठरत नाही.

🔧 कसे (या repo मध्ये)

sec/identity.py मध्ये: hash_password(password, salt=None, iterations=200_000) random 16-byte salt बनवते आणि (salt, iterations, pbkdf2_hmac("sha256", …)) परत देते. verify_password(password, stored) साठवलेल्या salt आणि iterations ने पुन्हा गणन करते आणि hmac.compare_digest ने तुलना करते. guesses_per_second(kind) मध्ये एका GPU साठी उदाहरणादाखल गोल आकडे आहेत, फरक किती मोठा आहे ते दाखवण्यासाठी — हा benchmark नाही.

🧪 करून पाहा

python3 sec/demo.py passwords
python3 - <<'EOF'
import sys, time; sys.path.insert(0, "sec"); from identity import hash_password, verify_password
a = hash_password("Summer2026!"); b = hash_password("Summer2026!")
print("same password, two users → same hash?", a[2] == b[2], "· salts differ?", a[0] != b[0])
print("right password →", verify_password("Summer2026!", a), "· one letter off →", verify_password("summer2026!", a))
for n in (1_000, 200_000, 600_000):
    t = time.perf_counter(); hash_password("Summer2026!", salt=b"s" * 16, iterations=n)
    print(f"{n:>7,} iterations → {(time.perf_counter() - t) * 1000:6.1f} ms per guess")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

passwords हे print करते:

── stored: salt + 200,000 PBKDF2 rounds → 7f2c954f85f5934bde900ac7… (never the password itself)
   login with the right password → True · wrong → False
── how fast can a stolen hash be guessed? (one GPU, illustrative)
   md5 (unsalted)             50,000,000,000 guesses/s
   sha256 (salted)            10,000,000,000 guesses/s
   pbkdf2 200k iterations             50,000 guesses/s
   use Argon2id / bcrypt / scrypt / PBKDF2 with a salt · add MFA · rate-limit logins · check breached passwords

तुमचा snippet हे print करतो (milliseconds तुमच्या machine वर अवलंबून — हे एका laptop वरचे आहेत):

same password, two users → same hash? False · salts differ? True
right password → True · one letter off → False
  1,000 iterations →    0.2 ms per guess
200,000 iterations →   48.9 ms per guess
600,000 iterations →  137.0 ms per guess

🏁 तुम्ही आत्ताच काय सिद्ध केले

एकाच password चे दोन वेगवेगळे hashes बनतात, कारण प्रत्येक user चे स्वतःचे salt असते. एक अक्षर बदलले तरी fail होते. आणि खर्च iterations सोबत वाढतो: 600,000 चा खर्च 200,000 च्या साधारण तिप्पट आहे. User login वेळी एकदाच 0.1 seconds थांबतो. चोर ती किंमत प्रत्येक अंदाजासाठी भरतो — आणि demo च्या आकड्यांनुसार, हळू KDF वर हल्ला करणे salt नसलेल्या MD5 पेक्षा दहा लाख पट हळू आहे.

⚠️ नेहमीच्या चुका

sha256(password) किंवा md5(password) — जलद hashes, salt असले तरी
सगळ्यांसाठी एकच global salt, किंवा random नसलेले salt
2015 मध्ये निवडलेला आणि कधीच न वाढवलेला work factor — पुढच्या login वेळी नव्या खर्चाने re-hash करा
timing मोजता येईल अशा code मध्ये hashes ची == ने तुलना करणे
"चुकीचा password" विरुद्ध "असा user नाही" असे messages जे अंदाज करणाऱ्याला कोणते emails आहेत ते सांगतात
staff आणि admin accounts साठी फक्त SMS ने MFA — passkeys किंवा authenticator app ला प्राधान्य द्या
login नंतरही तोच session id ठेवणे (session fixation)

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — library वापरा; KDF कधीही स्वतः लिहू नका. Python मध्ये Argon2id (argon2-cffi; त्याचे defaults RFC 9106 पाळतात):

from argon2 import PasswordHasher
ph = PasswordHasher()
stored = ph.hash(password)                    # "$argon2id$v=19$m=65536,t=3,p=4$…" — salt included
ph.verify(stored, attempt)                    # raises VerifyMismatchError when wrong
if ph.check_needs_rehash(stored):             # the cost was raised since this hash was made
    stored = ph.hash(attempt)

Node.js मध्ये bcrypt:

import bcrypt from 'bcrypt';
const stored = await bcrypt.hash(password, 12);        // cost 12
const ok = await bcrypt.compare(attempt, stored);

Django — Argon2 पहिला ठेवा; जुने hashes पुढच्या login वेळी upgrade होतात:

PASSWORD_HASHERS = [
    "django.contrib.auth.hashers.Argon2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
    "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
]

req.session.regenerate(err => { if (err) return next(err); req.session.userId = user.id; res.redirect('/'); });

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: शक्य असेल तर passwords अजिबात साठवू नका — passkeys आणि MFA देणारा managed identity provider (धडा 05) वापरा. साठवावेच लागले तर, library सह Argon2id वापरा, login route rate-limit करा, आणि नवे passwords breached-password यादीशी तपासा (उदाहरणार्थ Have I Been Pwned ची k-anonymity range API).

⏭️ पुढे

अनेक apps नी passwords तपासूच नयेत. ती म्हणतात "school account ने login करा" आणि token घेतात. पुढे: OAuth 2 आणि OpenID Connect — आणि token ने पार कराव्या लागणाऱ्या सगळ्या तपासण्या.

git checkout lesson-05-oauth-oidc

🔑 Lesson 04 — Authentication: proving who you are

📍 You are here: Lesson 04 of 16 · Previous: lesson-03-browser-server · Next: lesson-05-oauth-oidc

📦 What's in this branch

Lessons 01–03, plus the first lesson of the ID desk. The school must store something that lets it check a password without storing the password. You hash a password with a salt and a slow key-derivation function (PBKDF2), check a right and a wrong login, and compare how fast a stolen hash can be guessed. Then MFA, passkeys, and sessions vs tokens. passwords() in sec/demo.py shows it.

🧒 Explain like I'm 5

The ID desk must check Katrina's secret word every morning. But it must never write the word down — a thief could steal the notebook.

So the desk does something clever. It takes Katrina's word, adds a random sticker only for her (the salt), and puts both into a very slow grinding machine. The machine turns the handle 200,000 times and gives out a smudge. The desk writes down the sticker and the smudge.

Tomorrow Katrina says her word again. The desk adds her sticker, grinds it again, and compares the smudges. Same smudge → same word.

A thief who steals the notebook sees only stickers and smudges. To find a word, he must guess, grind 200,000 turns, compare — for every guess, for every pupil, because everyone's sticker is different. That is slow on purpose.

And for important doors, the desk asks for a second thing too — a code from Katrina's phone, or her passkey. A stolen word alone is not enough.

🗺️ Diagram

flowchart LR
    pw["🔤 password"] --> kdf["🐢 slow KDF<br/>PBKDF2-SHA256 × 200,000<br/>(Argon2id in production)"]
    salt["🎲 random salt<br/>16 bytes, per user"] --> kdf
    kdf --> store["📒 stored: salt + iterations + hash<br/>never the password"]
    login["🔤 login attempt"] --> kdf2["🐢 same KDF, same salt"]
    store --> kdf2
    kdf2 --> cmp{"constant-time<br/>compare"}
    cmp -->|"match"| mfa["📱 second factor<br/>TOTP · passkey"]
    mfa --> sess["🍪 new session id"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l04

❓ What

Authentication — proving who you are. (Authorization — what you may do — is lesson 06.) Failures here are A07:2021 – Identification and Authentication Failures.
Never store passwords — not in plain text, not encrypted (a key can leak), not with a fast hash (MD5, SHA-256).
Salt — random bytes, different for every user, stored next to the hash. Two users with the same password get different hashes, and a thief cannot use one pre-computed table for everyone.
Slow key-derivation function (KDF) — a hash designed to be expensive, with a work factor you can raise over time. OWASP's Password Storage Cheat Sheet (2023) recommends:
- Argon2id first (minimum 19 MiB of memory, 2 iterations, 1 degree of parallelism),
- scrypt if Argon2id is not available,
- bcrypt for older systems (work factor 10 or more; it reads only the first 72 bytes),
- PBKDF2-HMAC-SHA256 with 600,000 iterations or more when FIPS-140 approval is required. The lab uses PBKDF2 with 200,000 iterations only so the demo runs fast — use the numbers above in real systems.
Constant-time compare — hmac.compare_digest takes the same time whether the first byte or the last byte differs, so timing leaks nothing.
MFA (multi-factor authentication) — something you know + something you have (a TOTP app, a security key) or are. Passkeys (WebAuthn / FIDO2) replace the password with a key pair on the device; the private key never leaves it, and it only answers to the real site, so it cannot be phished.
Other login defences — rate limits and lock-outs with back-off, checking new passwords against lists of breached passwords, and generic error messages ("wrong email or password").
Sessions vs tokens — after login the server issues either a random session id in an HttpOnly cookie (the server keeps the state; easy to revoke) or a signed token such as a JWT (the state is inside it; hard to revoke before it expires). Issue a new session id at login, so an id planted before login is useless.

🤔 Why

Because password databases leak — through SQL injection (lesson 01), a lost backup, or a careless log. When they leak, the only thing between the thief and your users' accounts — and every other site where they reused the password — is how slow the hash is. A fast hash on a GPU is guessed billions of times a second. A slow, salted one only thousands. MFA and passkeys make a guessed password not enough on its own.

🔧 How (in this repo)

In sec/identity.py: hash_password(password, salt=None, iterations=200_000) makes a random 16-byte salt and returns (salt, iterations, pbkdf2_hmac("sha256", …)). verify_password(password, stored) recomputes with the stored salt and iterations and compares with hmac.compare_digest. guesses_per_second(kind) holds illustrative round numbers for one GPU, to show the size of the gap — not a benchmark.

🧪 Try it

python3 sec/demo.py passwords
python3 - <<'EOF'
import sys, time; sys.path.insert(0, "sec"); from identity import hash_password, verify_password
a = hash_password("Summer2026!"); b = hash_password("Summer2026!")
print("same password, two users → same hash?", a[2] == b[2], "· salts differ?", a[0] != b[0])
print("right password →", verify_password("Summer2026!", a), "· one letter off →", verify_password("summer2026!", a))
for n in (1_000, 200_000, 600_000):
    t = time.perf_counter(); hash_password("Summer2026!", salt=b"s" * 16, iterations=n)
    print(f"{n:>7,} iterations → {(time.perf_counter() - t) * 1000:6.1f} ms per guess")
EOF

✅ Verify — what you should see

passwords prints:

── stored: salt + 200,000 PBKDF2 rounds → 7f2c954f85f5934bde900ac7… (never the password itself)
   login with the right password → True · wrong → False
── how fast can a stolen hash be guessed? (one GPU, illustrative)
   md5 (unsalted)             50,000,000,000 guesses/s
   sha256 (salted)            10,000,000,000 guesses/s
   pbkdf2 200k iterations             50,000 guesses/s
   use Argon2id / bcrypt / scrypt / PBKDF2 with a salt · add MFA · rate-limit logins · check breached passwords

Your snippet prints (the milliseconds depend on your machine — these are from one laptop):

same password, two users → same hash? False · salts differ? True
right password → True · one letter off → False
  1,000 iterations →    0.2 ms per guess
200,000 iterations →   48.9 ms per guess
600,000 iterations →  137.0 ms per guess

🏁 What you just proved

The same password gives two different hashes, because each user has their own salt. A single changed letter fails. And the cost grows with the iterations: 600,000 costs about three times 200,000. A user waits 0.1 seconds once, at login. A thief pays that price for every guess — and in the demo's numbers, a slow KDF is a million times slower to attack than an unsalted MD5.

⚠️ Common mistakes

sha256(password) or md5(password) — fast hashes, even with a salt
one global salt for everyone, or a salt that is not random
a work factor chosen in 2015 and never raised — re-hash at the next login with the new cost
comparing hashes with == in code where timing can be measured
"wrong password" vs "no such user" messages that tell a guesser which emails exist
MFA by SMS only, for staff and admin accounts — prefer passkeys or an authenticator app
keeping the same session id after login (session fixation)

🏭 In production

On a real account — use a library; never write the KDF yourself. Argon2id in Python (argon2-cffi; its defaults follow RFC 9106):

from argon2 import PasswordHasher
ph = PasswordHasher()
stored = ph.hash(password)                    # "$argon2id$v=19$m=65536,t=3,p=4$…" — salt included
ph.verify(stored, attempt)                    # raises VerifyMismatchError when wrong
if ph.check_needs_rehash(stored):             # the cost was raised since this hash was made
    stored = ph.hash(attempt)

bcrypt in Node.js:

import bcrypt from 'bcrypt';
const stored = await bcrypt.hash(password, 12);        // cost 12
const ok = await bcrypt.compare(attempt, stored);

Django — put Argon2 first; older hashes are upgraded at the next login:

PASSWORD_HASHERS = [
    "django.contrib.auth.hashers.Argon2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
    "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
]

Issue a fresh session id at login (Express with express-session):

req.session.regenerate(err => { if (err) return next(err); req.session.userId = user.id; res.redirect('/'); });

🏭 Why this matters in production: if you can, do not store passwords at all — use a managed identity provider (lesson 05) that offers passkeys and MFA. If you must store them, use Argon2id with a library, rate-limit the login route, and check new passwords against a breached-password list (for example the k-anonymity range API of Have I Been Pwned).

⏭️ Next

Many apps should not check passwords at all. They say "log in with the school account" and receive a token. Next: OAuth 2 and OpenID Connect — and every check a token must pass.

git checkout lesson-05-oauth-oidc

← Previousbrowser server Next →oauth oidc

This page is the lesson's README from the lesson-04-authentication branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.