मुफ़्त बल्क पासवर्ड जनरेटर

बल्क पासवर्ड जनरेशन

यह टूल एक ही ऑपरेशन में कई क्रिप्टोग्राफ़िक रूप से मज़बूत पासवर्ड जनरेट करता है। ऑनबोर्डिंग के लिए सूचियाँ तैयार करने के लिए उपयुक्त।

मज़बूती स्तर

• कमज़ोर · 8-11 वर्ण: बुनियादी सुरक्षा, संवेदनशील खातों के लिए बचें
• ठीक · 12-15 वर्ण: मध्यम सुरक्षा, कई उपयोगों के लिए स्वीकार्य
• अच्छा · 16-19 वर्ण: मज़बूत सुरक्षा, अधिकांश खातों के लिए अनुशंसित
• बहुत मज़बूत · 20 या अधिक वर्ण: अधिकतम सुरक्षा, महत्वपूर्ण सिस्टम के लिए आदर्श

अक्सर पूछे जाने वाले प्रश्न

क्या ये पासवर्ड वास्तव में यादृच्छिक हैं?

हाँ। पासवर्ड window.crypto.getRandomValues() के साथ जनरेट होते हैं, जो क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक मान प्रदान करता है।

क्या मैं 100 से अधिक पासवर्ड जनरेट कर सकता हूँ?

ब्राउज़र को धीमा होने से बचाने के लिए टूल एक बार में 100 तक सीमित करता है। यदि आवश्यक हो तो कई बैच अलग-अलग जनरेट करें।

डाउनलोड की गई फ़ाइल कैसे संग्रहीत करें?

.txt फ़ाइल को सुरक्षित स्थान पर, अधिमानतः एन्क्रिप्टेड, रखें। इसे कभी कोड रिपोज़िटरी में कमिट या साझा न करें।

अच्छे random numbers कहाँ से आते हैं

एक computer, डिज़ाइन से, deterministic होता है। एक ही inputs और एक ही code दिए जाने पर, यह हर बार एक ही outputs तैयार करता है। यह ठीक वही property है जो आप spreadsheet चला रहे CPU से चाहते हैं, और ठीक वही property है जो आप password generator से नहीं चाहते। यदि कोई attacker generator द्वारा emit किए गए values के sequence को reproduce कर सके, तो वे हर password reproduce कर सकता है जो उसने कभी जारी किया।

तो generator «entropy» (program के बाहर से unpredictable physical signal) collect करता है और इसका उपयोग एक algorithm को seed करने के लिए करता है जिसे CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) कहा जाता है। «pseudo» honest है: bits एक algorithm द्वारा बनाए जाते हैं, physics द्वारा नहीं। «cryptographically secure» का अर्थ है कि यहाँ तक कि एक attacker जो past outputs की एक लंबी run देखता है, अगले byte की chance से बेहतर भविष्यवाणी नहीं कर सकता। Theodore Ts'o ने 1994 में Linux kernel में /dev/random implement किया, और macOS, BSDs, Solaris और Windows (with BCryptGenRandom) ने equivalent interfaces adopt किए। ये हर possible source of physical jitter (disk-seek timing, network packet arrivals, keyboard और mouse input, hardware interrupts, उन Intel CPUs पर RDRAND जिनमें यह है) को एक cryptographic hash के माध्यम से mix करते हैं, फिर continuously reseed करते हैं।

browser में, W3C Web Cryptography API इसे window.crypto.getRandomValues(typedArray) के माध्यम से expose करती है: इसे एक typed array दें, browser इसे cryptographically strong random bytes से भर देता है। प्रति call maximum 65,536 bytes है (यह tool इससे काफी कम रहता है)। API को जुलाई 2015 से Chrome, Firefox, Safari और Edge में baseline-supported किया गया है: इस बात की कोई realistic संभावना नहीं है कि कोई user इस tool पर ऐसे browser से आए जिसमें यह नहीं है।

Password entropy, असली गणित

Password «strength,» formal cryptographic sense में, bits of entropy में मापी जाती है। एक randomly generated password के लिए standard formula है:

एन्ट्रॉपी = L × log₂(R)

जहाँ L characters में length है और R character pool का आकार है। प्रत्येक character की charset के अनुसार entropy:

• केवल अंक (0-9): 10 chars → 3.32 bits/char
• केवल lowercase (a-z): 26 → 4.70 bits/char
• छोटे + बड़े अक्षर (A-Za-z): 52 → 5.70 bits/char
• छोटे + बड़े अक्षर + अंक (alphanumeric): 62 → 5.95 bits/char
• सभी printable ASCII, space को छोड़कर: 94 → 6.55 bits/char

94 की संख्या को ध्यान से समझना उचित है: ASCII codes 32 से 126 तक printable characters हैं (कुल 95); space को छोड़ने पर 94 visible non-space glyphs बचते हैं (26 lowercase + 26 uppercase + 10 digits + 32 punctuation/symbols)। Formula में concrete numbers डालने पर:

• 8 chars × 6.55 ≈ 52.4 bits: modern hardware पर brute-force करना आसान
• 12 chars × 6.55 ≈ 78.6 bits: borderline, 80-bit threshold से थोड़ा कम
• 16 chars × 6.55 ≈ 104.8 bits: 100 से ऊपर, ANSSI-acceptable territory में
• 20 chars × 6.55 ≈ 131.0 bits: AES-128-equivalent threshold से पार
• 32 chars × 6.55 ≈ 209.6 bits: किसी भी conceivable adversary के लिए overkill

cryptographic community ने तीन thresholds पर सहमति बनाई है: 80 bits न्यूनतम सीमा के रूप में (NIST का 2014 तक recommended floor), full 94-char set के साथ ~13 characters पर पहुँचता है; 100 bits ANSSI (NSA का French equivalent) द्वारा encryption systems की रक्षा करने वाले passwords के लिए required, ~16 characters पर पहुँचता है; और 128 bits AES-128 की symmetric-key strength से मेल खाता है, vault master passwords के लिए recommended, ~20 characters पर पहुँचता है।

एक बड़ी चेतावनी: यह गणित केवल random passwords पर लागू होता है। यदि किसी मानव ने password चुना है, तो effective entropy बहुत, बहुत कम है। attacker R^L strings को alphabetically enumerate नहीं कर रहा, वे leaked password lists, dictionary words, common substitutions (a→@, o→0, s→$), keyboard walks, और मनुष्य memorable strings कैसे बनाते हैं इसके statistical models से seeded guessing program चला रहे हैं। 70 million Yahoo passwords के anonymised corpus पर Joseph Bonneau का 2012 study (IEEE Symposium on Security and Privacy) ने पाया कि user-chosen passwords «an online trawling attack के विरुद्ध 10 bits से कम security देते हैं, और optimal offline dictionary attack के विरुद्ध केवल लगभग 20 bits।» बीस bits एक million guesses है। एक modern GPU यह microseconds में कर लेती है।

NIST SP 800-63B, 2017 में और फिर 2025 में क्या बदला

लगभग तीस वर्षों तक, passwords पर North American security नीति एक 1985 NIST publication से उतरी जिसने forced periodic rotation, mixed character classes और short minimum lengths की सिफारिश की। Bill Burr, 2003 के follow-up के लेखक जिसने «uppercase + lowercase + digit + symbol, हर 90 दिन में बदलें» नियम को codify किया, ने 2017 में इसे सार्वजनिक रूप से वापस लिया, Wall Street Journal को बताते हुए कि «मैंने जो कुछ किया, उसमें से अधिकांश के लिए मुझे अब पछतावा है।» NIST ने उसी वर्ष reversal को formalize किया।

NIST SP 800-63B Rev 3 (जून 2017) ने दो generational बदलाव किए। Section 5.1.1.2 में लिखा है: «Verifiers को memorized secrets को arbitrarily (जैसे, periodically) बदलने की आवश्यकता नहीं होनी चाहिए», क्योंकि forced rotations users को कमज़ोर, अधिक predictable passwords चुनने पर मजबूर करते हैं। वही section: «Verifiers को memorized secrets के लिए अन्य composition rules (जैसे, अलग character types के mixtures की आवश्यकता) नहीं लगाने चाहिए», क्योंकि एक digit और एक symbol को force करने से users एक longer passphrase के बजाय Password1! की ओर जाते हैं। Rev 3 ने minimum subscriber-chosen length 8 characters पर set की, verifiers को 64 तक accept करने की आवश्यकता बनाई, नए passwords को breach blocklists के विरुद्ध check करना अनिवार्य किया, और explicitly password managers और clipboard pastes की अनुमति देने की आवश्यकता बनाई।

NIST SP 800-63B Rev 4 (31 जुलाई 2025 को finalize) ने मानक को कड़ा किया: single-factor passwords के लिए अब 15-character minimum आवश्यक है («Verifiers और CSPs को ऐसे passwords के लिए जो single-factor authentication mechanism के रूप में उपयोग किए जाते हैं, कम से कम 15 characters की लंबाई की आवश्यकता रखनी होगी»)। Multi-factor passwords 8 characters पर रहते हैं क्योंकि दूसरा factor security weight वहन करता है। Composition rules अभी भी prohibited हैं, और wording Rev 3 के «SHOULD NOT» से Rev 4 के «SHALL NOT» में shift हो गई, जो इसे recommendation के बजाय एक hard requirement बनाती है। Rotation अभी भी discouraged है जब तक compromise का कोई evidence न हो।

Absolutool tool default रूप से सभी चार character classes के साथ 16 characters का उपयोग करता है, जो लगभग 104 bits of entropy देता है और 15-character Rev 4 minimum और 80-bit symmetric-equivalence threshold दोनों को आरामदायक रूप से पार करता है। Tool का 128 characters का maximum, NIST द्वारा निर्धारित उस maximum length का ठीक दोगुना है जिसे verifiers को स्वीकार करना होगा, ऐसा कोई realistic case नहीं है जहाँ generated password server के लिए बहुत लंबा हो।

RockYou, वह disaster जो 2026 में भी सता रहा है

दिसंबर 2009 में, social games company RockYou को textbook SQL injection के माध्यम से breach किया गया। breach ने 32 million से अधिक user accounts को expose किया, जिसमें उन accounts के passwords plaintext में शामिल थे: RockYou ने उन्हें unencrypted store किया था। उस समय company की password policy में केवल पाँच characters की आवश्यकता थी और special characters अनुमत नहीं थे, जिसने vulnerability को और बढ़ाया।

breach हुई file, जल्दी ही rockyou.txt उपनाम से जानी गई, publicly प्रकाशित हुई और दुनिया की सबसे अधिक referenced password wordlist बनी हुई है। यह penetration testers के लिए Kali Linux के साथ default रूप से ship होती है; दुनिया का हर dictionary attack tool इसके विरुद्ध check करता है; commercial credential-stuffing services इसे baseline के रूप में maintain करती हैं। सोलह साल बाद भी, attackers उन passwords से live accounts पकड़ते हैं जो पहली बार 2009 leak में दिखे। जो lessons फैले: servers को कभी plaintext passwords नहीं देखने चाहिए (यह tool client-side generate करता है, इसलिए server उन्हें बिल्कुल नहीं देखता); stored passwords को Argon2id या bcrypt जैसे slow, salted, memory-hard function से hash किया जाना चाहिए, न कि MD5 या unsalted SHA-1 जैसे fast hash से; प्रति site unique passwords ही stolen-credentials replay attack के विरुद्ध एकमात्र defence है जिसने पिछले दशक के breaches पर dominate किया है।

Have I Been Pwned और breach corpus

Have I Been Pwned (HIBP), Microsoft Regional Director Troy Hunt द्वारा संचालित, «क्या यह password किसी breach में दिखाई दिया है?» के लिए standard authoritative source बन गया है। Hunt ने 2013 में HIBP को breached email addresses के searchable index के रूप में launch किया; उन्होंने बाद में Pwned Passwords corpus जोड़ा, किसी public breach में देखे गए हर password की एक downloadable list, SHA-1 hash द्वारा indexed। Pwned Passwords V2, 22 फरवरी 2018 को launch हुई और dataset का k-anonymity API (Cloudflare के साथ built) पेश किया: एक client SHA-1 hash के केवल पहले पाँच characters भेजता है; server उन पाँच characters से शुरू होने वाले हर full hash को observed count के साथ return करता है; client locally compare करता है। password (और उसका full hash भी) कभी user के device से नहीं निकलता।

bulk generator के लिए, relevance दो प्रकार की है। HIBP में पहले से मौजूद कोई भी password, परिभाषा से, एक useful नया password नहीं है, यह पहली चीज़ होगी जो कोई भी credential-stuffing attacker try करेगा। और क्योंकि यह tool 94-character alphabet से full CSPRNG randomness के साथ generate करता है, यह probability कि एक freshly generated 16-character password HIBP में पहले से है, practical purposes के लिए, शून्य है। (16-character ASCII-symbol passwords की कुल संख्या 94^16 ≈ 3.7 × 10³¹ है; HIBP में लगभग 10⁹ known passwords हैं; collision probability ≈ 10⁻²².)

«X bits of entropy» का वास्तविक time-to-crack में क्या अर्थ है

bits of entropy को concrete meaning देने वाली संख्या «एक modern attacker को कितना समय चाहिए?» है, और इसका उत्तर पूरी तरह hash algorithm पर निर्भर करता है। एक single Nvidia RTX 4090 पर hashcat v6.2.6 के लिए community-published benchmark NTLM hashes (Microsoft का पुराना Windows hash) के लिए लगभग 300 GH/s और bcrypt के लिए 200 kH/s record करता है। उन दोनों के बीच four-orders-of-magnitude का अंतर load-bearing fact है: NTLM को speed के लिए design किया गया था, bcrypt को slow होने के लिए।

व्यापक रूप से उद्धृत Hive Systems password tables benchmarks को time-to-crack numbers में बदलती हैं। MD5 hashes के विरुद्ध computed 2025 version (लगभग NTLM जितना तेज़) full charset से 8-character password को brute-force करने के लिए एक RTX 4090 पर ~59 minutes देता है। वही 8-character password bcrypt hash के विरुद्ध उसी hardware पर ~99 years लेता है। वह four-orders-of-magnitude का अंतर «कल leak हुआ, lunchtime तक crack हो गया» और «कल leak हुआ, आपसे लंबा जिएगा» के बीच का अंतर है।

end user password length और charset control करता है। वे server द्वारा इसे store करने के लिए उपयोग किए जाने वाले hash algorithm को नहीं control करते। अधिकांश well-run modern services bcrypt, scrypt या Argon2id का उपयोग करती हैं, सभी deliberately slow। पुरानी services और breached services ने अक्सर MD5 या unsalted SHA-1 का उपयोग किया, इसीलिए पुराने breach corpora को ऊपर उद्धृत speeds पर crack किया जा सकता है। इस tool द्वारा generated password के लिए: एक 16-character random password essentially हमेशा के लिए bcrypt-safe है और अभी के लिए MD5-safe-ish है; एक 20-character password दोनों के विरुद्ध overkill है। ऐसा कोई realistic threat model नहीं है जहाँ CSPRNG output के 20+ characters weak link हों।

FIDO2, WebAuthn और passkey transition

security industry में सबसे लंबे समय से चली आ रही prediction यह है कि passwords खत्म हो जाएंगे। 2019 से आखिरकार एक credible replacement आया है: passkeys, FIDO2 / WebAuthn standards के अंतर्गत issued credentials का consumer-marketing नाम। WebAuthn Level 1, 4 मार्च 2019 को W3C Recommendation बन गया; Level 2, 8 अप्रैल 2021 को आया। cryptographic model asymmetric है: जब कोई user register करता है, authenticator एक public/private keypair generate करता है, server को public key भेजता है, और private key को secure local hardware में store करता है। Authentication private key से signed एक challenge-response का उपयोग करता है। Server कभी secret नहीं देखता, जिसका अर्थ है कि server-side breach login credentials expose नहीं कर सकता।

major platform rollouts 2022-2023 के दौरान lockstep में आगे बढ़े: Apple ने 6 जून 2022 को WWDC में passkeys demo किए और उन्हें सितंबर 2022 में iOS 16, iPadOS 16 और macOS Ventura के साथ publicly ship किया, end-to-end encrypted iCloud Keychain के माध्यम से sync। Google ने 12 अक्टूबर 2022 को Android और Chrome के लिए passkey support announce किया; stable Chrome support दिसंबर 2022 में Chrome 108 में आई, Google Password Manager के माध्यम से syncing। Microsoft ने 21 सितंबर 2023 को Windows 11 के लिए passkey management announce किया, Windows Hello के साथ integrated।

Passkeys password failure के सबसे कठिन classes (phishing, credential stuffing, server breach) को हल करते हैं, लेकिन उन्होंने passwords को खत्म नहीं किया है क्योंकि: कई sites और अधिकांश legacy systems अभी भी एक की आवश्यकता करते हैं; passkeys एक device या sync ecosystem से बंधे हैं (Apple, Google या Microsoft account के बिना users को alternative की आवश्यकता है); headless systems (IoT devices, server-side service accounts, batch-onboarding scenarios) registration step पर biometric authenticator पर rely नहीं कर सकते; और कई enterprise password policies, banking systems और government portals अभी भी passwords अनिवार्य करते हैं। Bulk password generation squarely second-and-third categories में है: 50 नए accounts provision करने वाला system administrator प्रत्येक future user से account exist होने से पहले passkey enrol करने के लिए नहीं कह सकता।

Client-side generation specifically क्यों मायने रखती है

कल्पना करें एक competitor tool जो user के request को server पर POST करता है, server random generator चलाता है, और list को JSON के रूप में return करता है। यदि सब कुछ advertised के अनुसार काम करे तब भी, निम्नलिखित parties generated passwords को cleartext में देख सकती हैं: request handle होते समय server की process memory; server के request logs (यदि logging naive है); कोई भी APM या error-tracking service जिससे server connected है; TLS-terminating reverse proxy (Cloudflare, AWS load balancer, nginx); server पर चल रहा कोई भी debugging tool; कोई भी future attacker जो उन logs में से किसी तक पहुँच जाए। RockYou model, अपने सभी consequences के साथ, लागू होता है।

जब generation user के browser में window.crypto.getRandomValues() के माध्यम से होती है, तो उनमें से कोई भी लागू नहीं होता। bytes browser process के अंदर, user की machine पर, उस code द्वारा produce होते हैं जिसे user audit कर सकता है (page viewable source है)। वे कभी network पार नहीं करते। Absolutool का server उन्हें कभी नहीं देखता, कभी log नहीं करता, और future breach में leak नहीं कर सकता क्योंकि उसके पास कभी थे ही नहीं। generated passwords देखने वाली एकमात्र entities user हैं, user के browser session तक पहुँच रखने वाला कोई भी (आमतौर पर केवल user), और page पर चल रहे कोई भी browser extensions। यह password manager के local generator जैसा ही security model है, और किसी भी ऐसी web service के model से stronger है जो server से generated passwords return करती है।

Mirai 2016, IoT defaults के लिए negative example

«हर unit पर एक ही default password रखें» का textbook negative example Mirai botnet है। Mirai ने late 2016 में लाखों IP cameras, DVRs और home routers को infect करने के लिए लगभग 62 manufacturer-default username/password combinations (admin/admin, root/root, root/xc3511, root/vizxv) की एक hardcoded list का फायदा उठाया, फिर 21 अक्टूबर 2016 को उनका उपयोग major DNS provider Dyn को down करने के लिए किया, जिसने briefly Twitter, Reddit, Netflix और GitHub को बाधित किया। एक bulk password generator alternative के लिए बिल्कुल सही primitive है: production line पर हर unit के लिए एक unique strong default तैयार करें, इसे sticker पर print करें, box के अंदर ship करें।

अधिक प्रश्न

NIST length को complexity से अधिक क्यों recommend करता है?

क्योंकि complexity (एक digit, एक symbol, एक uppercase letter) को force करने से users उन predictable patterns में जाते हैं जिन्हें attacker ने पहले से model किया है। Password1! गणितीय रूप से password से अधिक entropy रखता है, लेकिन व्यवहार में हर attacker की wordlist वहीं से शुरू होती है। CSPRNG से एक 20-character all-lowercase string में ~94 bits of entropy है और इसे किसी wordlist से guess नहीं किया जा सकता क्योंकि यह किसी wordlist से match नहीं करता। NIST SP 800-63B Rev 4 (जुलाई 2025) composition rules के prohibition को एक hard SHALL NOT requirement बनाता है।

क्या मुझे इसके बजाय passphrases का उपयोग करना चाहिए?

जिन passwords को आपको याद रखना है, उनके लिए हाँ, यही xkcd #936 (10 अगस्त 2011) तर्क दे रहा था। Diceware method (Arnold Reinhold, 1995) एक 7,776-word list से प्रति word 12.9 bits देता है; six words ≈ 77.5 bits आधुनिक recommendation है। EFF ने जुलाई 2016 में updated diceware-compatible word lists जारी कीं। लेकिन इस tool के bulk-provisioning use case के लिए (temporary tokens जो first login पर बदल जाते हैं) random ASCII सही primitive है क्योंकि user को इसे कभी type नहीं करना होता।

Ambiguous characters को exclude करना एक security trade-off है?

हाँ, technically, i, l, 1, L, O, 0, o को drop करने से alphabet 94 से 87 हो जाता है, per-character entropy 6.55 bits से 6.44 bits हो जाती है। 16 characters पर यह 104.8 bits के बजाय 103.0 bits है, पूरी तरह irrelevant। trade-off तब worthwhile होता है जब मनुष्यों को password को जोर से पढ़ना हो या इसे printed sheet से transcribe करना हो, जो exactly वह bulk-distribution scenario है जिसे यह tool serve करता है।

Generated list distribute करने का सबसे सुरक्षित तरीका क्या है?

generated list को एक one-shot artifact मानें। एक pre-arranged channel के माध्यम से distribute करें (PGP/GPG के साथ encrypted email, secure file transfer, password manager import, high-stakes contexts के लिए in-person sneakernet)। Systems को first login पर password change की आवश्यकता रखने के लिए configure करें। distribution के बाद file delete करें। कभी plaintext lists email न करें, कभी उन्हें version control में commit न करें, कभी उन्हें chat में paste न करें। generated passwords one-time tokens के रूप में intended हैं, value initial handover के लिए cryptographic randomness में है, long-term retention में नहीं।

संबंधित टूल