रैंडम Base64 जनरेटर

अपने ब्राउज़र के सुरक्षित रैंडम नंबर जनरेटर से रैंडम Base64 स्ट्रिंग बनाएँ। लंबाई बाइट या अक्षरों में तय करें, एक बार में 1000 तक स्ट्रिंग जनरेट करें, और मानक या URL-सुरक्षित आउटपुट चुनें।

पूरी तरह आपके ब्राउज़र में चलता है। कुछ भी अपलोड नहीं होता।

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

  1. “लंबाई” सेट करें और “इकाई” में चुनें कि वह रैंडम डेटा के बाइट गिनती है या Base64 अक्षर। कुंजी के लिए बाइट का उपयोग करें: 32 बाइट का मतलब 256-बिट कुंजी है।
  2. जितनी स्ट्रिंग चाहिए, उतनी “संख्या” सेट करें और उनके बीच का “विभाजक” चुनें: नई लाइन, कॉमा या स्पेस।
  3. “मानक” या “URL-सुरक्षित” वेरिएंट चुनें। बाइट इकाई के साथ आप “पैडिंग” भी बंद कर सकते हैं, अगर लक्ष्य सिस्टम = चिह्नों की अपेक्षा नहीं करता।
  4. नए मान पाने के लिए “जनरेट करें” पर क्लिक करें, फिर सूची को “सब कॉपी करें” से कॉपी करें या “डाउनलोड करें” से डाउनलोड करें।

बाइट, अक्षर और एंट्रॉपी

किसी रैंडम स्ट्रिंग की मज़बूती एंट्रॉपी के बिट में मापी जाती है। हर रैंडम बाइट 8 बिट जोड़ता है, इसलिए 16 बाइट से 128 बिट और 32 बाइट से 256 बिट मिलते हैं। Base64 केवल यह बदलता है कि ये बाइट किस रूप में लिखे जाते हैं: हर अक्षर 6 बिट रखता है, और हर 3 बाइट 4 अक्षर बन जाते हैं। टूल हर स्ट्रिंग की एंट्रॉपी दिखाता है, ताकि आप एक नज़र में उसे जाँच सकें।

रैंडम डेटा के बाइट इकाई के साथ आउटपुट डिकोड होकर ठीक उतने ही रैंडम बाइट देता है, और कुंजियों व सीक्रेट को यही चाहिए। अक्षर इकाई के साथ आपको ठीक उतने ही अक्षर मिलते हैं, और हर अक्षर 64 अक्षरों की वर्णमाला में से बराबर संभावना के साथ चुना जाता है; इसका उपयोग तब करें जब कोई सिस्टम तय लंबाई का टोकन माँगता हो और उसे टेक्स्ट के रूप में सहेजता हो।

बाइटBase64 अक्षरएंट्रॉपीआम उपयोग
121696 बिटAES-GCM nonce (IV)
1624 (पैडिंग के बिना 22)128 बिटसॉल्ट, सेशन और CSRF टोकन, AES-128 कुंजियाँ
3244 (पैडिंग के बिना 43)256 बिटAES-256 और HMAC-SHA256 कुंजियाँ, HS256 सीक्रेट, API कुंजियाँ
6488 (पैडिंग के बिना 86)512 बिटHMAC-SHA512 कुंजियाँ, HS512 सीक्रेट

रैंडम Base64 मान कहाँ उपयोग होते हैं

  • JWT सीक्रेट। RFC 7518 के अनुसार HMAC कुंजी कम से कम हैश आउटपुट जितनी लंबी होनी चाहिए: HS256 के लिए 32 बाइट, HS384 के लिए 48 और HS512 के लिए 64। कुछ लाइब्रेरी सीक्रेट स्ट्रिंग को जैसी है वैसी ही इस्तेमाल करती हैं, जबकि दूसरी पहले उसे Base64 से डिकोड करती हैं, इसलिए जाँच लें कि आपकी लाइब्रेरी किसकी अपेक्षा करती है। JWT डिकोडर दोनों तरह के सीक्रेट के साथ HS256 से HS512 तक के सिग्नेचर सत्यापित करता है, और HMAC जनरेटर कुंजी को टेक्स्ट, हेक्स या Base64 के रूप में स्वीकार करता है।
  • एप्लिकेशन कुंजियाँ। उदाहरण के लिए, Laravel अपनी 32-बाइट एन्क्रिप्शन कुंजी को .env फ़ाइल में APP_KEY=base64:... के रूप में रखता है, जो इस टूल से बनी 32-बाइट स्ट्रिंग जैसा ही रूप है।
  • Kubernetes Secrets। data के अंतर्गत मान पैडिंग वाले मानक Base64 में होने चाहिए। बाइट मोड में, मानक वेरिएंट और चालू पैडिंग के साथ बनी स्ट्रिंग सीधे वहाँ रखी जा सकती है, और Pod को रॉ रैंडम बाइट मिलते हैं। अगर एप्लिकेशन ख़ुद Base64 टेक्स्ट की अपेक्षा करता है, तो उसे इसके बजाय stringData के अंतर्गत रखें।
  • URL में टोकन। पासवर्ड रीसेट लिंक, आमंत्रण कोड और URL में भेजे जाने वाले दूसरे टोकन के लिए URL-सुरक्षित वेरिएंट का उपयोग करना चाहिए, जो + और / को - और _ से बदल देता है। विवरण के लिए Base64URL देखें।

Math.random के बजाय crypto.getRandomValues क्यों

Math.random() एक तेज़, सामान्य उपयोग वाला जनरेटर है। इसका आउटपुट अप्रत्याशित होने के लिए नहीं बनाया गया है, और कुछ इंजनों में केवल गिने-चुने मानों से इसकी आंतरिक स्थिति दोबारा बनाई जा सकती है। यह टूल crypto.getRandomValues() का उपयोग करता है, जो ऑपरेटिंग सिस्टम से सीड पाने वाला क्रिप्टोग्राफ़िक रूप से सुरक्षित जनरेटर है, यानी उसी तरह का स्रोत जो openssl rand और Python के secrets मॉड्यूल के पीछे है। मान आपके डिवाइस पर बनते हैं और कभी भेजे या सहेजे नहीं जाते।

कोड में रैंडम Base64 जनरेट करें

# Shell: 32 रैंडम बाइट Base64 के रूप में (44 अक्षर)
openssl rand -base64 32
head -c 32 /dev/urandom | base64

# Python
import base64, secrets
base64.b64encode(secrets.token_bytes(32)).decode()
secrets.token_urlsafe(32)        # URL-सुरक्षित, पैडिंग नहीं, 43 अक्षर

// Node.js
const crypto = require('crypto');
crypto.randomBytes(32).toString('base64');
crypto.randomBytes(32).toString('base64url');   // URL-सुरक्षित, पैडिंग नहीं

// ब्राउज़र
const bytes = crypto.getRandomValues(new Uint8Array(32));
btoa(String.fromCharCode(...bytes));

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

रैंडम कुंजी या सीक्रेट कितना लंबा होना चाहिए?

जिन मानों का केवल अद्वितीय और अनुमान से परे होना ज़रूरी है, जैसे सेशन ID, CSRF टोकन और सॉल्ट, उनके लिए 16 बाइट (128 बिट) काफ़ी हैं। AES-256 कुंजियों, HMAC-SHA256 कुंजियों और HS256 सीक्रेट के लिए 32 बाइट (256 बिट), और HMAC-SHA512 व HS512 के लिए 64 बाइट का उपयोग करें।

क्या यह openssl rand -base64 32 जैसा ही है?
यह उसी तरह का मान बनाता है। लंबाई 32 बाइट, “मानक” वेरिएंट और चालू पैडिंग के साथ हर परिणाम 44 अक्षर लंबा होता है, एक = पर समाप्त होता है और डिकोड होकर 32 रैंडम बाइट देता है। ज़ाहिर है, मान ख़ुद हर बार अलग होते हैं।
मुझे बाइट इकाई चुननी चाहिए या अक्षर इकाई?

जब स्ट्रिंग को डिकोड किया जाएगा, जैसे एन्क्रिप्शन कुंजियों और Kubernetes Secrets में, तब बाइट का उपयोग करें। जब किसी सिस्टम को ठीक तय लंबाई का टोकन चाहिए और वह टेक्स्ट को जैसा है वैसा ही इस्तेमाल करता है, तब अक्षर का उपयोग करें। अक्षर इकाई से बनी स्ट्रिंग के ठीक से डिकोड होने की गारंटी तभी है जब उसकी लंबाई 4 का गुणज हो।

URL-सुरक्षित वेरिएंट की ज़रूरत कब होती है?
जब भी मान किसी URL, क्वेरी स्ट्रिंग, कुकी या फ़ाइल नाम में जाता है। मानक Base64 में / URL पाथ को बाँट देता है और फ़ॉर्म-एनकोड की गई क्वेरी स्ट्रिंग में + स्पेस बन जाता है। URL-सुरक्षित Base64 इनकी जगह - और _ का उपयोग करता है और आमतौर पर बिना पैडिंग के लिखा जाता है।
क्या जनरेट किए गए मान कहीं सहेजे या भेजे जाते हैं?

नहीं। वे आपके ब्राउज़र में JavaScript द्वारा बनाए जाते हैं, कभी भेजे नहीं जाते और पेज छोड़ते ही मिट जाते हैं। किसी मान को असली सीक्रेट के रूप में इस्तेमाल करना शुरू करने के बाद उसे चैट संदेशों या टिकट में नहीं, बल्कि पासवर्ड मैनेजर या सीक्रेट स्टोर में रखें।