पासवर्ड हैश करने से असल में किससे सुरक्षा मिलती है

संक्षिप्त संस्करण

पासवर्ड को hash करना users की रक्षा तब करता है जब आपका password database चोरी हो जाता है।

यही इसका मुख्य काम है। यह न तो केवल एक detail है, न पूरा security model, लेकिन passwords को सीधे store करने के बजाय hash करने का केंद्रीय कारण यही है।

ठीक से hash किया गया password reverse करना कठिन होता है। अगर किसी attacker को आपकी user table की copy मिल जाती है, तो उसे तुरंत यह नहीं पता चलना चाहिए कि Alice का password Spring2026! है। इसके बजाय, उसे एक stored hash मिलता है जिसे guesses के खिलाफ test करने में time, money, और hardware लगता है।

यह फर्क महत्वपूर्ण है। Password hashing का उद्देश्य login को अपने-आप secure बना देना नहीं है। यह phishing को नहीं रोकती। यह किसी को आपके login form के खिलाफ leaked passwords आज़माने से नहीं रोकती। यह login के बाद session cookie की रक्षा नहीं करती। यह समय खरीदती है और एक बहुत specific failure के बाद नुकसान कम करती है: आपका password verifier storage exposed हो जाता है।

अगर आप इस boundary को समझते हैं, तो आप algorithms, work factors, resets, logging, और incident response के बारे में बेहतर निर्णय लेंगे।

Password hash क्या होता है

Password hash, password पर apply किए गए one-way function का output होता है, आमतौर पर एक unique salt और जानबूझकर slow password-hashing algorithm के साथ।

जब कोई user account बनाता है, तो system को लगभग यह करना चाहिए:

1. HTTPS पर password receive करें।
2. एक random, unique salt generate करें।
3. password और salt को Argon2id, bcrypt, scrypt, या PBKDF2 जैसे password-hashing function से चलाएँ।
4. algorithm name, parameters, salt, और resulting hash store करें।
5. original password discard करें।

जब user बाद में login करता है, तो system submitted password और stored parameters के साथ वही hashing process repeat करता है। अगर resulting hash stored hash से match करता है, तो login सफल होता है।

महत्वपूर्ण बात: application को original password जानने की जरूरत नहीं होती। उसे केवल यह verify करना होता है कि submitted password expected result produce करता है।

इसीलिए reversible encryption के साथ passwords store करना आमतौर पर गलत model है। अगर आपकी application हर password decrypt कर सकती है, तो decryption key चुराने वाला कोई भी व्यक्ति वही कर सकता है। Passwords को सामान्यतः reverse में unverifiable होना चाहिए, केवल hidden नहीं।

Hashing आपको किससे बचाती है

1. Database breach के बाद immediate password disclosure

अगर कोई attacker plaintext passwords वाला database चुरा लेता है, तो नुकसान तुरंत होता है। हर password exposed हो जाता है। Users केवल आपकी site पर ही नहीं, बल्कि जहाँ भी उन्होंने वह password reuse किया है, वहाँ भी risk में होते हैं।

अगर database में well-hashed passwords हैं, तो attacker को अधिक काम करना पड़ता है। उसे candidate passwords guess करने होते हैं, हर guess को correct salt और parameters के साथ hash करना होता है, और result compare करना होता है।

Weak passwords के लिए यह फिर भी तेज़ हो सकता है। Strong unique passwords के लिए यह impractical हो सकता है।

Hashing एक catastrophic disclosure को race में बदल देती है: क्या users passwords reset कर सकते हैं और क्या आप attackers द्वारा उनमें से कई को crack करने से पहले incident contain कर सकते हैं?

यह perfect नहीं है। यह फिर भी breach है। लेकिन यह नाटकीय रूप से बेहतर failure mode है।

2. आपके पूरे user base के खिलाफ bulk attacks

Salts password storage का key part हैं क्योंकि वे attackers को precomputed tables के साथ कई users पर efficiently attack करने से रोकते हैं।

Salt secret नहीं होता। यह hash के साथ store किया जाता है। इसका काम uniqueness है।

अगर दो users वही password चुनते हैं, तो unique salts सुनिश्चित करते हैं कि उनके stored hashes अलग हों। इससे attackers एक नज़र में यह नहीं देख पाते कि कई users का same password है। यह classic rainbow table attacks को भी रोकता है, जहाँ attackers password-to-hash mappings की huge precomputed lists use करते हैं।

Salts के बिना, एक cracked hash same password वाले हर user को reveal कर सकता है। Salts के साथ, हर password guess को हर user के लिए अलग से test करना पड़ता है।

3. Fast offline guessing

एक बार attackers के पास password database आ जाए, तो वे offline guess कर सकते हैं। इसका मतलब है कि आपकी login rate limits, CAPTCHA, IP blocking, और monitoring अब matter नहीं करतीं। Attacker अपने hardware पर guesses test कर सकता है।

यहीं algorithm choice महत्वपूर्ण होती है।

SHA-256 और SHA-512 जैसे general-purpose hashes fast होने के लिए design किए गए हैं। यह file integrity और digital signatures के लिए अच्छा है। Password storage के लिए खराब है।

Password-hashing algorithms slow, tunable, और कभी-कभी memory-hard होने के लिए design किए जाते हैं। Argon2id, bcrypt, scrypt, और PBKDF2 सभी आपको cost parameters adjust करने देते हैं ताकि हर guess में meaningful time लगे।

Argon2id नए systems के लिए व्यापक रूप से recommended है क्योंकि इसे CPU time और memory दोनों require करने के लिए configure किया जा सकता है, जिससे large-scale GPU cracking अधिक महंगी हो जाती है। bcrypt अब भी common और acceptable है जब इसे अच्छी तरह configure किया जाए, हालांकि password length handling जैसी इसकी limitations हैं। PBKDF2 अब भी कुछ compliance-driven environments में use होता है, खासकर जहाँ FIPS-validated components required होते हैं।

Principle simple है: legitimate logins को acceptably fast रखें, जबकि billions of guesses को expensive बनाएँ।

Hashing आपको किससे नहीं बचाती

1. Phishing

अगर कोई user अपना password fake login page में type करता है, तो आपके server पर hashing मदद नहीं करती। Attacker को password आपके system के देखने से पहले ही मिल जाता है।

यहाँ defenses अलग हैं: multi-factor authentication, passkeys, user education, domain hygiene, phishing-resistant authentication, और careful password reset flows।

Password hashing stored secrets के लिए backstop है। यह users को धोखे से वे secrets देने से रोकने की defense नहीं है।

2. Credential stuffing

Credential stuffing तब होता है जब attackers एक service से leaked username और password pairs लेकर उन्हें दूसरी service पर आज़माते हैं।

आपके password hashes excellent हो सकते हैं, और credential stuffing फिर भी काम कर सकती है अगर users passwords reuse करते हैं।

यह आपके login form के खिलाफ online attack है, आपके database के खिलाफ offline attack नहीं। आपको rate limiting, anomaly detection, breached-password checks, MFA, और sensible lockout policies चाहिए जो आसान denial-of-service opportunities create न करें।

यही practical thinking किसी भी exposed form पर लागू होती है। अगर आप अपनी authentication surface review कर रहे हैं, तो यह पढ़ना उपयोगी है कि आपका contact form आपकी सबसे बड़ी spam liability क्यों है; mechanics अलग हैं, लेकिन lesson मिलता-जुलता है: public inputs को abuse controls चाहिए, केवल clean backend code नहीं।

3. Logs या analytics में capture हुए passwords

Hashing तभी मदद करती है जब plaintext password जल्दी discard हो जाए और कहीं और copy न हो।

Common failures में शामिल हैं:

• Failed login attempts पर full request bodies log करना।
• Passwords को error monitoring tools में भेजना।
• Session replay products में password fields capture करना।
• Poorly designed reset या migration flows में credentials को URLs में include करना।
• Imports के दौरान temporary plaintext passwords store करना।

ये mistakes password hashing को पूरी तरह bypass कर देती हैं। अगर plaintext logs, backups, data warehouses, या third-party tools में पहुँच जाता है, तो आपका hash function irrelevant है।

Password fields को toxic data की तरह treat करें। Logging से पहले उन्हें redact करें। Analytics से exclude करें। उन्हें URLs से बाहर रखें। Production traces तक access किसे है, इसे limit करें।

4. Bad session security

Login के बाद, user के browser को आमतौर पर session cookie या token मिलता है। अगर वह token चोरी हो जाता है, तो attacker को password की बिल्कुल जरूरत नहीं हो सकती।

Password hashing cross-site scripting, insecure cookies, session fixation, weak token generation, या बहुत लंबी session lifetimes से protect नहीं करती।

Session cookies अपनी अलग review deserve करती हैं: HttpOnly, Secure, appropriate SameSite, short-lived high-risk sessions, और password changes पर server-side invalidation। व्यापक privacy और browser landscape भी बदलता रहता है, जैसा कि 2026 में cookies के लिए क्या बदला में बताया गया है।

5. Weak password reset और account recovery

कई account takeovers password से शुरू नहीं होते। वे reset flow से शुरू होते हैं।

अगर reset tokens predictable, long-lived, referrer headers के जरिए leaked, या compromised email accounts पर sent हैं, तो password hashing आपको नहीं बचाएगी।

High-entropy reset tokens, short expiry windows, one-time use, और clear user notifications use करें। चूँकि email अक्सर recovery channel होता है, basic domain authentication भी मायने रखता है। अगर आपकी team DNS records को mysterious ceremony की तरह treat करती है, तो MX, SPF, DKIM और DMARC का developer-friendly tour से शुरू करें।

Algorithm choice: अभी क्या use करें

नई applications के लिए, अगर आपका platform इसे अच्छी तरह support करता है, तो Argon2id use करें। यह Password Hashing Competition का winner है और password storage के लिए design किया गया है, जिसमें GPU-heavy cracking के खिलाफ resistance भी शामिल है।

एक reasonable modern hierarchy कुछ ऐसी दिखती है:

1. Argon2id नए systems के लिए जहाँ available हो।
2. bcrypt जब Argon2id practical न हो और bcrypt support mature हो।
3. scrypt जब memory-hard configuration अच्छी तरह supported हो।
4. PBKDF2 जहाँ platform या compliance constraints के कारण required हो।

Plain SHA-256, SHA-512, MD5, या sha256(password + salt) जैसी homegrown combination से बचें। Fast hashes password storage functions नहीं हैं। Clever custom constructions अक्सर boring standard ones से खराब होते हैं।

Algorithm trivia के around अपनी password policy invent करने से भी बचें। Users को 12-rule password composition checklist से फायदा नहीं होता अगर वह उन्हें predictable patterns की ओर धकेलती है। Longer unique passwords, password managers, breached-password screening, और MFA आमतौर पर अधिक matter करते हैं।

Cost factors set-and-forget नहीं होते

Password hashing के parameters होते हैं। Argon2id में memory, iterations, और parallelism होते हैं। bcrypt में cost factor होता है। PBKDF2 में iteration count होता है।

इन values को आपके production environment के आधार पर choose किया जाना चाहिए। बहुत low हों, तो attackers सस्ते में guess करते हैं। बहुत high हों, तो आपका login system slow हो जाता है या denial-of-service के लिए vulnerable हो सकता है।

एक practical target अक्सर आपके actual servers पर प्रति password verification tens से कुछ hundreds of milliseconds की range में होता है, traffic और risk पर depend करते हुए। High-security systems अधिक choose कर सकते हैं। Consumer-scale systems को careful capacity planning चाहिए हो सकती है।

पाँच साल पुराने blog post से cost factor copy न करें। Hardware बदलता है। Libraries बदलती हैं। आपका traffic बदलता है।

Parameters को periodically review करें और rehashing की योजना बनाएँ। एक common pattern है कि algorithm और parameters को हर hash के साथ store किया जाए। Successful login पर, अगर stored parameters outdated हैं, तो submitted password को newer configuration के साथ rehash करें और record update करें।

Peppers: उपयोगी, लेकिन substitute नहीं

Pepper एक secret value है जिसे password-hashing process में add किया जाता है और database से अलग store किया जाता है, अक्सर secrets manager या hardware security module में।

Salt के विपरीत, pepper secret रहना चाहिए।

Peppers नुकसान कम कर सकते हैं अगर database leak हो जाए लेकिन application secrets न हों। वे good key management वाले mature environments में सबसे अधिक useful हैं। वे कम useful हैं अगर वही attacker database और application configuration दोनों चुरा सकता है।

अगर आप pepper use करते हैं, तो rotation सावधानी से plan करें। Design के आधार पर इसे rotate करने के लिए users को फिर से login करना या passwords reset करना पड़ सकता है। Pepper एक additional layer है, underlying hash settings को weaken करने का कारण नहीं।

Operational checklist

अगर आप किसी real system के responsible हैं, तो practical checklist छोटी है:

• Passwords को केवल standard password-hashing algorithm के साथ store करें।
• हर password के लिए unique random salt use करें।
• New builds के लिए Argon2id prefer करें।
• Production-like hardware पर cost parameters tune करें।
• हर hash के साथ algorithm और parameters store करें।
• Parameters outdated होने पर login पर rehash करें।
• Passwords कभी log न करें या analytics tools को न भेजें।
• जहाँ भी credentials submit होते हैं, वहाँ TLS use करें।
• जहाँ risk justify करता है, वहाँ MFA या passkeys add करें।
• Reset flows को login flows जितनी गंभीरता से protect करें।
• Forced resets और user notification के लिए incident plan रखें।

Password hashing glamorous नहीं है। यह plumbing है। लेकिन यह ऐसी plumbing है जो तय करती है कि breach एक painful incident बनेगा या user-wide disaster।

<!-- tool-cta:start -->

💡 इसे आज़माएँ: Hash Generator के साथ देखें कि वही इनपुट अलग-अलग एल्गोरिदम से कैसे मैप होता है, जो तेज़ हैश और पासवर्ड-ग्रेड हैश के बीच के अंतर को ठोस बनाता है।

<!-- tool-cta:end -->

ईमानदार mental model

Password hashing के बारे में सोचने का सबसे अच्छा तरीका यह है:

Hashing user द्वारा password type करते समय password की रक्षा नहीं करती। यह user के logged in होने के बाद account की रक्षा नहीं करती। यह उन users की रक्षा नहीं करती जो web पर passwords reuse करते हैं।

यह stored verifier की रक्षा करती है।

यह narrow लगता है, लेकिन अत्यंत महत्वपूर्ण है। Databases leak होते हैं। Backups leak होते हैं। Staging systems copy हो जाते हैं। Vendors को ऐसा access मिल जाता है जो उन्हें नहीं मिलना चाहिए। पुराने exports object storage में किसी की याद से भी अधिक समय तक पड़े रहते हैं।

जब ऐसा होता है, तो आपका password storage design attackers को passwords मिलने और attackers को एक expensive guessing problem मिलने के बीच का फर्क बन जाता है।

Password hash करने से असल में यही सुरक्षा मिलती है।