Bcrypt Generator — ऑनलाइन पासवर्ड hash बनाएँ

पासवर्ड को hash करना आसान है। उसे उस तरीके से करना, जैसा आधुनिक application को करना चाहिए, उतना स्पष्ट नहीं है, क्योंकि algorithm का चुनाव यह तय करता है कि offline हमला कितना समय लेगा, और सही जवाब आपके hardware और आपके threat model पर निर्भर करता है। bcrypt पासवर्ड storage की मुख्य अनुशंसा दो दशक से अधिक समय से है, क्योंकि यह जानबूझकर धीमा है और क्योंकि इसकी लागत समायोज्य है: वही algorithm आज एक साधारण server पर 100 मिलीलीटर ले सकता है और दस साल बाद तेज़ मशीन पर 250 मिलीलीटर, जबकि hash साथ रखने वाला हमलावर हर अनुमान पर पूरी यह कीमत चुकाता है। यह मुफ्त bcrypt generator आपके दर्ज किए किसी भी पासवर्ड के लिए असली, सही प्रारूप वाला bcrypt hash बनाता है, और आपको work factor खुद तय करने देता है यह भी दिखाकर कि उसकी लागत मिलीलीटर में लगभग कितनी पड़ेगी। यह मौजूदा hash की पुष्टि भी करता है, और यही वह चरण है जिसे लोग भूल जाते हैं: पासवर्ड की तुलना संग्रहीत hash से करना hash बनाने से पूरी तरह अलग कार्रवाई है, और यहाँ दोनों उपलब्ध हैं। हर गणना client-side आपके ब्राउज़र में चलती है, इसलिए सादा पाठ वाला पासवर्ड किसी server को कभी नहीं भेजा, लॉग नहीं होता और कहीं संग्रहीत नहीं होता। यह मायने रखता है, क्योंकि पासवर्ड hashing tool पर तभी भरोसा किया जा सकता है जब वह आपके hash होने वाले मान को देख ही न सके, और यह उसे कभी नहीं मिलता।

Bcrypt Generator

Hashing runs locally in your browser. Your password is never uploaded or stored.

पासवर्ड

Cost factor (rounds) — 12

41215

Store the entire hash string including the version prefix, cost and salt — bcrypt needs all of it to verify later.

क्या है

पासवर्ड hash एक one-way function है जो पासवर्ड को निश्चित लंबाई वाली string में बदल देता है, इस तरह कि मूल पासवर्ड उसमें से निकाला न जा सके, लेकिन वही पासवर्ड बाद में दोबारा hash करके उस hash से मिलाया जा सकता है। bcrypt वही विशिष्ट algorithm है जिसे यह टूल लागू करता है, जिसे Niels Provos और David Mazieres ने बनाया और 1999 में OpenBSD के password hashing scheme के रूप में जारी किया। यह adaptive या जानबूझकर महँगी key derivation functions के परिवार से है और Blowfish block cipher पर बना है। संरचनागत रूप से, bcrypt एक random 128-bit salt बनाता है, उसे पासवर्ड के साथ मिलाता है, फिर महँगी EksBlowfish key schedule को समायोज्य संख्या बार चलाता है, जहाँ वह संख्या काम की लागत का log base 2 होती है। चूँकि यह salt आउटपुट में अंतर्निहित रहता है, इसलिए एक ही पासवर्ड के दो bcrypt hash अलग-अलग string होते हैं, जिससे हमलावर उन खातों को पहचान नहीं पाता जो एक ही पासवर्ड साझा करते हैं। आउटपुट modular crypt format का उपयोग करता है: पहले एक version prefix, फिर cost, फिर salt का 22 अक्षरों वाला base64 encoding, फिर निकले हुए hash का 31 अक्षरों वाला encoding, सब dollar चिह्नों से अलग किए गए। व्यवहार में दो परिणाम मायने रखते हैं। पहला, bcrypt 72 bytes से आगे की input चुपचाप अनदेखी कर देता है, इसलिए उससे लंबा कोई भी पासवर्ड bcrypt से पहले pre-hash होना चाहिए, वरना prefix साझा करने वाले दो लंबे पासवर्ड एक-दूसरे की जगह ले लेंगे। दूसरा, algorithm जानबूझकर one-way है: पुष्टि के लिए सादा पासवर्ड चाहिए, और यही कारण है कि bcrypt कभी भी ऐसी किसी चीज़ के लिए नहीं इस्तेमाल होना चाहिए जिसे आपको वापस पढ़ना हो, जैसे कार्ड नंबर याद रखना।

कैसे उपयोग करें

Bcrypt Generator को अपने ब्राउज़र में खोलें। Hashing स्थानीय रूप से होती है, इसलिए आपका पासवर्ड कहीं अपलोड नहीं होता।
जिस पासवर्ड को hash करना है उसे इनपुट खाने में लिखें। लंबा passphrase विचार करें, क्योंकि लंबाई symbol बदलने से कहीं अधिक प्रतिरोध देती है।
4 से 15 के बीच कोई work factor चुनें, या यदि आप निश्चित नहीं हैं तो अनुशंसित default पर ही छोड़ दें। अधिक cost में समय अनुपात के अनुसार बढ़ता है और हमला कठिन होता है।
cost के साथ दिखाया गया समय जाँचें और पुष्टि करें कि वह आपके लक्ष्य से मेल खाता है, जो production hardware पर आम तौर से 150 से 400 मिलीलीटर के बीच होता है।
Hash बनाने के लिए Generate पर क्लिक करें, फिर निकली हुई string को version prefix, cost और salt सहित अपने password store में कॉपी करें।
किसी integration का परीक्षण करते समय या संग्रहीत credentials migrate करते समय verify अनुभाग से पासवर्ड को मौजूदा hash के विरुद्ध जाँचें।
केवल उसकी पूँछ नहीं, पूरी hash string संग्रहीत करें, क्योंकि bcrypt को बाद में पुष्टि करने के लिए version, cost और salt prefix मौजूद होना आवश्यक है।

उदाहरण

इनपुट: Password: correct-horse-battery-staple, cost 10

प्रक्रिया:

128-bit random salt, 2^10 EksBlowfish चक्कर, base64 encode

परिणाम: 60 अक्षरों का hash जो $2b$10$ से शुरू होता है — पुष्टि के लिए वही सादा पाठ चाहिए

इनपुट: एक ही पासवर्ड को एक ही cost पर दो बार hash किया गया

प्रक्रिया:

हर invocation पर एक नया random salt बनता है

परिणाम: एक जैसे input के लिए दो पूरी तरह अलग hash string

इनपुट: सामान्य server hardware पर cost की तुलना

प्रक्रिया:

Cost 10 में 2^10 चक्कर, cost 12 में 2^12, cost 14 में 2^14

परिणाम: हर बढ़त लगभग चार गुना काम, यानी cost 14 का समय cost 10 से लगभग 16x

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

bcrypt के लिए कौन सा cost factor चुनना चाहिए?

अधिकांश production systems के लिए work factor 12 एक ठीक default है, जो सामान्य server hardware पर प्रति hash लगभग 250 से 400 मिलीलीटर देता है, जबकि cost 10 अब अक्सर आधुनिक GPUs वाले समर्पित हमलावर के विरुद्ध टिकने के लिए बहुत तेज़ है। महत्वपूर्ण गुण यह है कि आपको वह आंकड़ा चुनना चाहिए जो आपके अपने login flow को साधारण महसूस कराए, क्योंकि hashing प्रमाणीकरण के दौरान होती है और जो कुछ स्पष्ट रूप से धीमा है वह usability समस्या बन जाती है जो लोगों को दोबारा प्रमाणीकरण के shortcut की ओर धकेलती है। यदि आपके servers असामान्य रूप से शक्तिशाली हैं, तो cost 12 पर मापें और 13 या 14 तक बढ़ाएँ जब तक एक hash कुछ सौ मिलीलीटर न ले। कभी भी किसी दूसरी परियोजना का आंकड़ा कॉपी करके cost तय न करें, क्योंकि वह आंकड़ा केवल उस hardware के सापेक्ष अर्थ रखता है जो काम कर रहा है, और किसी भी संग्रहीत cost को समय के साथ दोबारा मापकर बढ़ाते रहें जैसे-जैसे hardware बेहतर हो।

एक ही पासवर्ड के दो hash अलग क्यों होते हैं?

क्योंकि bcrypt हर एक hash के लिए एक नया random 128-bit salt बनाता है। यह salt कोई रहस्य नहीं है, वह बस आउटपुट में दर्ज रहता है ताकि पुष्टि का चरण मूल गणना दोबारा बना सके, पर इसकी randomness सुनिश्चित करती है कि एक जैसे पासवर्ड अलग-अलग खातों में पूरी तरह असंबद्ध hash string बनाएँ। इससे precomputation attacks की एक बड़ी श्रेणी नाकाम हो जाती है, जिनमें rainbow tables भी शामिल हैं, जहाँ हमलावर हर संभावित पासवर्ड को पहले एक बार hash करके रखता है और फिर मिलान देखता है। यह एक सूक्ष्म leak भी रोकता है, जहाँ आपका user table हाथ में आ जाने पर हमलावर hash strings की तुलना करके तुरंत देख सकता था कि किन खातों का पासवर्ड एक जैसा है। व्यावहारिक निहितार्थ यह है कि आप संग्रहीत bcrypt hashes की तुलना करके दोबारा उपयोग का पता नहीं लगा सकते, और जाँच उम्मीदवार पासवर्ड verify करके ही करनी पड़ती है, और इसीलिए दोबारा उपयोग का पता लगाने के लिए दूसरे खातों पर पासवर्ड जानबूझकर आज़माना पड़ता है।

पासवर्ड संग्रहीत करने के लिए bcrypt बेहतर है या SHA-256?

bcrypt इस्तेमाल करें, और वजह कोई चतुर गणित नहीं बल्कि cost factor है। SHA-256 का एक चक्कर अत्यंत तेज़ चलने के लिए बनाया गया है, और पासवर्ड storage के लिए आपको ठीक यही नहीं चाहिए, क्योंकि एक GPU प्रति सेकंड करोड़ों की गणना कर सकता है और किसी ने leak हुई hash table के साथ परीक्षण करने वाले हमलावर को मुफ़्त अनुमानों की भारी संख्या मिल जाती है। bcrypt जानबूझकर धीमा है और इसकी प्रति hash लागत समायोज्य है, इसलिए आप hardware बेहतर होने के साथ इसे बढ़ा सकते हैं बिना संग्रहीत प्रारूप बदले। Argon2id अब जहाँ उपलब्ध हो वहाँ अक्सर पसंद किया जाता है और नए systems के लिए आम तौर पर वही मज़बूत सिफ़ारिश है, जबकि bcrypt पूरी तरह स्वीकार्य और बहुत व्यापक रूप से समर्थित बना रहता है। कभी भी पासवर्ड को सादा SHA-256, या किसी भी प्रकार के unsalted hash के रूप में संग्रहीत न करें, चाहे आप कोई भी algorithm चुनें।

क्या bcrypt hash को वापस मूल पासवर्ड में बदला जा सकता है?

नहीं, और पासवर्ड hash को encryption के बजाय चुनने का पूरा मकसद यही है। bcrypt एक one-way function है, इसलिए कोई key, कोई setting और कोई paid tool ऐसा नहीं है जो hash को पासवर्ड में वापस बदल दे। bcrypt hash से पासवर्ड वापस पाने का व्यावहारिक तरीका केवल यही है कि उम्मीदवार पासवर्डों का अनुमान लगाया जाए, हर एक को उसी cost और salt से hash किया जाए, और तुलना की जाए, और यही वह हमला है जिसे bcrypt धीमा करने के लिए बनाया गया है। इससे एक ऐसी शर्त भी समझ आती है जो लोगों को चौंका देती है: आप bcrypt का उपयोग ऐसी किसी चीज़ के लिए नहीं कर सकते जिसे आपको बाद में वापस पढ़ना हो, जैसे संग्रहीत कार्ड नंबर, ग्राहक encryption keys या reversible password recovery, क्योंकि सिस्टम मूल मान निकाल ही नहीं पाएगा। इनके लिए प्रबंधित key के साथ असली encryption चाहिए, one-way hash नहीं।

Hash संग्रहीत करते समय cost और salt भूल जाऊँ तो क्या होगा?

तब hash की कभी पुष्टि नहीं हो पाएगी और खाता बचा ही नहीं, क्योंकि bcrypt को गणना दोबारा बनाने के लिए string के चारों हिस्सों की ज़रूरत है। पूरा bcrypt hash होता है version prefix, cost, salt और निकला हुआ hash, dollar चिह्नों से जुड़ा हुआ, और वह हमेशा ठीक 60 अक्षर लंबा होता है। bcryptjs और Python के bcrypt package जैसी libraries एक ही generate call से पूरी string लौटाती हैं, इसलिए आपके database column में छँटा हुआ हिस्सा नहीं, पूरा मान संग्रहीत होना चाहिए। केवल अंतिम खंड, या केवल salt के बाद का हिस्सा संग्रहीत करने से हर उपयोगकर्ता का login चुपचाप टूट जाता है, और पासवर्ड की जितनी भी debugging की जाए कुछ नहीं होता। जिस column में bcrypt hashes रखने हैं, वहाँ 60 अक्षरों की लंबाई जाँचना एक उपयोगी sanity test है।

क्या bcrypt में पासवर्ड की कोई अधिकतम लंबाई है?

bcrypt पासवर्ड के केवल पहले 72 bytes देखता है और उसके आगे की हर चीज़ अनदेखी कर देता है, जो उसके Blowfish key schedule का ऐतिहासिक अवशेष है, कोई जानबूझकर सुरक्षा सीमा नहीं। व्यावहारिक परिणाम यह है कि 72 bytes से लंबे दो पासवर्ड, जो prefix साझा करते हैं, एक-दूसरे के विरुद्ध authenticate कर लेंगे, यानी 100 अक्षरों वाला passphrase जिसके पहले 72 bytes किसी दूसरे से मिलते हैं, वह उसी पासवर्ड माना जाएगा। यह लंबे passphrase के साथ वास्तविक जोखिम है, और लंबा passphrase ही वह चीज़ है जिसे आपको प्रोत्साहित करना चाहिए, तथा पूरे वाक्य जैसे लंबे मान आराम से सीमा से आगे निकल सकते हैं। मानक उपाय यह है कि पासवर्ड को पहले SHA-256 और base64 से pre-hash करें, फिर उस निश्चित लंबाई वाले परिणाम को bcrypt में दें। यदि आपकी भाषा की library यह स्वतः संभाल लेती है, तो उसी implementation को चुनें, वरना बहुत लंबे passphrase पर निर्भर रहने से पहले व्यवहार जाँच लें।

संबंधित टूल्स

एमडी5 हैश जनरेटर

किसी भी पाठ इनपुट से तत्काल MD5 हैश मान उत्पन्न करें। MD5 (मैसेज डाइजेस्ट एल्गोरिदम 5) एक 128-बिट का हैश मान उत्पन्न करता है जिसका उपयोग आमतौर पर डेटा अखंडता सत्यापन और चेकसम उत्पन्न करने के लिए किया जाता है। हालाँकि ज्ञात संघर्ष दुर्बलताओं के कारण MD5 को अब एन्क्रिप्शन उद्देश्यों के लिए सुरक्षित नहीं माना जाता, फिर भी इसका उपयोग गैर-सुरक्षा-महत्वपूर्ण अनुप्रयोगों जैसे फ़ाइल अखंडता जाँच, कैश कुंजियाँ और त्वरित डेटा फिंगरप्रिंटिंग में व्यापक रूप से किया जाता है।हमारा मुफ्त ब्राउज़र-आधारित उपकरण स्थानीय रूप से MD5 हैश गणना करता है — आपका डेटा कभी भी आपके डिवाइस से बाहर नहीं जाता, जिससे संवेदनशील डेटा की पूर्ण गोपनीयता सुनिश्चित होती है।

SHA-1 हैश जनरेटर

किसी भी टेक्स्ट इनपुट से तुरंत SHA-1 हैश मान उत्पन्न करें। SHA-1 (सिक्योर हैश एल्गोरिदम 1) एक 160-बिट हैश मान उत्पन्न करता है जिसका व्यापक रूप से सुरक्षा प्रोटोकॉल और संस्करण नियंत्रण प्रणालियों में उपयोग किया गया है। जबकि SHA-1 को प्रदर्शित कोलिजन हमलों के कारण क्रिप्टोग्राफिक उद्देश्यों के लिए अब अप्रचलित कर दिया गया है, यह Git कमिट पहचान, लीगेसी सिस्टम संगतता, और गैर-सुरक्षा फिंगरप्रिंटिंग कार्यों के लिए आवश्यक बना हुआ है। हमारा मुफ्त ब्राउज़र-आधारित टूल आपके डेटा को किसी सर्वर पर प्रेषित किए बिना स्थानीय रूप से SHA-1 हैश की गणना करता है।

SHA-256 हैश जनरेटर

किसी भी टेक्स्ट इनपुट से तुरंत SHA-256 हैश वैल्यू जनरेट करें। SHA-256 (सिक्योर हैश एल्गोरिदम 256-बिट) क्रिप्टोग्राफिक हैशिंग के लिए वर्तमान स्वर्ण मानक है, जो बिटकॉइन माइनिंग, ब्लॉकचेन तकनीक, SSL/TLS प्रमाणपत्र और आधुनिक सुरक्षा प्रोटोकॉल को संचालित करता है। कोई ज्ञात व्यावहारिक कोलिजन हमले न होने के कारण, SHA-256 सबसे मांग वाले अनुप्रयोगों के लिए उपयुक्त 256-बिट सुरक्षा शक्ति प्रदान करता है। हमारा मुफ़्त ब्राउज़र-आधारित टूल SHA-256 हैश की गणना स्थानीय रूप से करता है, यह सुनिश्चित करता है कि आपका संवेदनशील डेटा आपके डिवाइस से कभी बाहर न जाए।

SHA-512 हैश जनरेटर

किसी भी पाठ इनपुट से तुरंत SHA-512 हैश मान उत्पन्न करें। SHA-512 (सुरक्षित हैश एल्गोरिदम 512-बिट) अपने 512-बिट आउटपुट के साथ SHA-2 परिवार में सर्वोच्च सुरक्षा स्तर प्रदान करता है, जिससे यह उन अनुप्रयोगों के लिए आदर्श है जिन्हें अधिकतम टकराव प्रतिरोध और भविष्य-प्रूफ सुरक्षा की आवश्यकता होती है। 64-बिट सिस्टम पर, SHA-512 अक्सर SHA-256 से बेहतर प्रदर्शन करता है और हैश लंबाई को दोगुना देता है। हमारा मुफ्त ब्राउज़र-आधारित उपकरण स्थानीय रूप से SHA-512 हैश गणना करता है, जिससे आपका डेटा पूरी तरह गोपनीय रहता है।

फ़ाइल हैश जनरेटर

किसी भी फ़ाइल के लिए सीधे अपने ब्राउज़र में ही कंप्यूटेशनल क्रिप्टोग्राफिक हैश मान तैयार करें। हमारा फ़ाइल हैश जनरेटर MD5, SHA-1, SHA-256 और SHA-512 एल्गोरिदम का समर्थन करता है, जिससे आप अपनी फ़ाइलों की अखंडता की पुष्टि कर सकते हैं, डाउनलोड की वैधता सत्यापित कर सकते हैं और बिना किसी सर्वर पर फ़ाइलें अपलोड किए ही चेकसम तैयार कर सकते हैं। पूरी हैशिंग प्रक्रिया ब्राउज़र के FileReader API का उपयोग करके स्थानीय रूप से चलती है, जिससे संवेदनशील फ़ाइलों के लिए पूर्ण गोपनीयता और सुरक्षा सुनिश्चित होती है।

एचएमएसी जनरेटर

टेक्स्ट इनपुट और एक गुप्त कुंजी से तुरंत HMAC (हैश-आधारित संदेश प्रमाणीकरण कोड) मान उत्पन्न करें। HMAC डेटा की अखंडता और प्रामाणिकता दोनों की पुष्टि करता है, जिससे यह API प्रमाणीकरण, संदेश हस्ताक्षरण और सुरक्षित संचार प्रोटोकॉल के लिए आवश्यक है। हमारा मुफ्त ब्राउज़र-आधारित उपकरण MD5, SHA-1, SHA-256 और SHA-512 हैश फ़ंक्शनों के साथ HMAC का समर्थन करता है तथा पूर्ण गोपनीयता के लिए सभी गणनाएँ स्थानीय रूप से करता है।

CRC-32 कैलकुलेटर - टेक्स्ट, हेक्स और फ़ाइल की चेकसम

CRC-32 निकालना तब आसान हो जाता है जब आपको ठीक-ठीक पता हो कि कौन-सा एल्गोरिदम बात कर रहा है, और तभी उलझन होती है, क्योंकि दो सवाल एक-दूसरे में मिल जाते हैं: गणना कैसे होती है, और चेकसम आख़िर काम आता क्यों है। गणना वही है जो ISO 3309 और ITU-T V.42 निर्धारित करते हैं, यानी रिवर्स्ड, टेबल-आधारित एल्गोरिदम, जो किसी भी बाइट अनुक्रम को लेकर 32 बिट का एक संख्या लौटाता है। लेकिन उसका उपयोग 'हैश' शब्द से कहीं अधिक सीमित है। CRC एक एरर-डिटेक्शन कोड है, कोई सुरक्षा साधन नहीं, और वह एक ही काम बहुत सस्ते में करने के लिए बना है: बताना कि कोई डेटा ब्लॉक रास्ते में खराब तो नहीं हो गया, चाहे शोर के कारण, खराब डिस्क सेक्टर के कारण, अधूरी डाउनलोड के कारण, या इसलिए कि किसी ने चुपचाप कॉपी बदल दी। यह मुफ़्त CRC-32 कैलकुलेटर वास्तविक काम में आने वाले तीनों इनपुट तरीकों को संभालता है। आप टेक्स्ट लिख सकते हैं, जिसे पहले UTF-8 में एनकोड किया जाता है, हेक्स बाइट्स चिपका सकते हैं, जो फ़र्मवेयर हेडर या नेटवर्क पैकेट जैसे बाइनरी पेलोड के लिए चाहिए, या कोई फ़ाइल चुन सकते हैं और पूरी सामग्री की चेकसम एक साथ निकाल सकते हैं। आउटपुट फ़ॉर्मेट चुनकर आप उसी 32 बिट संख्या को हेक्साडेसिमल, दशमलव, अष्टक, 32-बिट बाइनरी या बेस 64 में देख सकते हैं, क्योंकि अपेक्षित रूप पूरी तरह इस पर निर्भर करता है कि वह मान कहाँ जा रहा है: संग्रह शीर्षक हेक्स रखते हैं, अधिकांश स्क्रिप्टिंग लाइब्रेरी इसे दशमलव पूर्णांक के रूप में छापती हैं, और कुछ प्रोटोकॉल चार कच्चे बाइट्स को बेस 64 में लपेटकर भेजते हैं। नीचे एक सारांश तालिका संदेश की लंबाई बाइट्स में और एक CRC-32b मान भी दिखाती है, जो आपके बाइट्स के अंत में एक शून्य बाइट जोड़कर निकाला गया होता है। सब कुछ आपके अपने कंप्यूटर पर जावास्क्रिप्ट से चलता है: आपका टेक्स्ट और आपकी फ़ाइल कभी अपलोड, लॉग या सहेजी नहीं जाती।

Bcrypt Generator — ऑनलाइन पासवर्ड hash बनाएँ