SaaS password storage: Argon2id hashing और migration guide
Adaptive password-hashing function जैसे Argon2id, unique salts, tuned work factors और safe rehashing से customer passwords सुरक्षित रखें; plaintext या तेज़ general-purpose hash कभी store न करें।
इस मार्गदर्शिका में
SaaS app को user passwords कैसे store करने चाहिए?
Password को plaintext या वापस पढ़ी जा सकने वाली encryption में store न करें। Argon2id जैसी dedicated adaptive password-hashing function से verifier बनाएँ, हर password के लिए unique salt रखें और production hardware पर cost settings test करें। Framework के supported password-hashing API का उपयोग करें ताकि parameters और migration एकसमान रहें। Hashing database leak का नुकसान घटाती है; phishing या reused credentials से live account की रक्षा अपने-आप नहीं करती।
Dedicated adaptive password-hashing function को प्राथमिकता दें
Runtime और deployment में समर्थित हो तो Argon2id उपयोग करें। OWASP की baseline configurations में 19 MiB memory, दो iterations और parallelism एक शामिल हैं; एक higher-memory equivalent भी दिया गया है। वर्तमान guidance देखें और system पर tune करें। Validated cryptographic module की policy हो तो documented PBKDF2 profile जैसा compliant विकल्प चुनें; हर library को स्वतः compliant न मानें।
Unique salt रखें और encoded verifier पूरा store करें
विश्वसनीय password-hashing library हर password के लिए नया salt बनाए और algorithm तथा cost metadata को encoded verifier में रखे। अपना salt format न बनाएँ, global salt reuse न करें और stored result से parameters न हटाएँ। Framework के verification function से candidate password जाँचें; constant-time behavior library से लें।
Password verification में तेज hashes और reversible storage से बचें
SHA-256 जैसे general-purpose hashes तेज़ बनाए गए हैं, इसलिए चोरी हुए hash पर बड़े पैमाने पर guesses करना आसान होता है। Encryption reversible है और ऐसे password के लिए सामान्यतः गलत storage model है जिसकी केवल verification चाहिए। घर पर undocumented sequence of hashes न बनाएँ; supported password hasher और upgrade path रखें।
| Runtime/framework | Algorithm और वर्तमान parameters | Login latency और capacity test | Legacy hash migration नियम | Owner और review date |
|---|---|---|---|---|
| Production web app | ||||
| Background authentication service | ||||
| Legacy imported accounts |
Team password hashes को tune और maintain कैसे करे?
User experience और abuse load, दोनों के अनुसार cost benchmark करें
मजबूत hash हर login और password change में अधिक काम करता है। Production जैसी instances पर benchmark करें, उचित latency target तय करें और peak concurrent sign-ins पर load test करें। Abusive attempts rate-limit कर capacity की योजना बनाएँ; admission control के बिना बहुत महँगी setting authentication को अनुपलब्ध कर सकती है।
Stored settings पुरानी हों तो सफल login के बाद rehash करें
सही password के बाद जाँचें कि stored verifier पुराना algorithm या कम work factor उपयोग तो नहीं करता। Framework समर्थन करे तो successful verification के बाद नया verifier बना कर सुरक्षित update करें। Dormant accounts और कमजोर legacy formats की recovery योजना रखें; one-way hash को उलटने की कोशिश न करें।
Optional pepper को अलग से managed secret मानें
Database से अलग, जैसे approved secret manager या key service में रखा pepper defense-in-depth जोड़ सकता है। इससे operations और recovery जटिल होते हैं; यह unique salt या मजबूत adaptive hash की जगह नहीं लेता। अपनाने से पहले rotation और incident handling लिखें।
Engineering team password storage को कैसे verify करे?
Live passwords उजागर किए बिना stored account records देखें
Controlled test database में हर account के encoded verifier, अलग salt और expected algorithm metadata की पुष्टि करें। Logs, analytics, support tools, exports और backups में plaintext password या reset token न हो। Staff user का मूल password निकाल न सके—system को उसे जानने योग्य नहीं होना चाहिए।
Verification, upgrade और failure behavior test करें
Valid/invalid password, account creation, password change और legacy rehash path जाँचें। Malformed या unknown hash format सुरक्षित रूप से fail हो और सामान्य authentication policy bypass न करे। Cost parameter बदलने के बाद peak login load चलाएँ और व्यापक rollout से पहले latency व errors देखें।
Legacy credentials से सुरक्षित migration plan बनाएँ
Hash algorithm और version की inventory रखें, पर credential material को reports में कॉपी न करें। Compatible हो तो successful login पर rehash करें; असुरक्षित या verify न हो सकने वाले format के लिए security और support owners से reset या staged migration का आकलन करें। Enumeration रोकें और MFA व session policy बनाए रखें।
SaaS password-storage के सवाल
क्या SaaS company ठीक से stored password hash को decrypt कर सकती है?
Password hash verification के लिए होता है, recovery के लिए नहीं। System candidate password जाँच सके, लेकिन मूल password निकाल न सके—ऐसी व्यवस्था होनी चाहिए।
क्या SHA-256 अच्छा password-hashing algorithm है?
अकेले नहीं। यह तेज़ है, इसलिए database चोरी होने पर attacker guesses जल्दी जाँच सकता है। Dedicated adaptive password hasher और tuned work factor अपनाएँ।
क्या bcrypt हर संभावित password length संभालता है?
सामान्य implementations में bcrypt की 72-byte सीमा होती है। अपनी library का व्यवहार जाँचें और चुपचाप truncation से बचें; जहाँ संभव हो आधुनिक hasher और एकसमान input rules अपनाएँ।
Hash cost बढ़ाने पर क्या सभी passwords reset करने होंगे?
अक्सर सफल login पर नया hash बनाया जा सकता है। कुछ असुरक्षित या verify न हो सकने वाले legacy formats में reset चाहिए हो सकता है; फैसला stored format और risk से करें, हर account पर अपने-आप reset न थोपें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .