hmac-bcrypt

इस रिपॉजिटरी में कई भाषाओं में hmac-bcrypt पासवर्ड हैशिंग फ़ंक्शन के संदर्भ कार्यान्वयन (reference implementations) शामिल हैं। प्रत्येक संदर्भ कार्यान्वयन, जहाँ संभव हो, @epixoip द्वारा बनाए गए मूल C और Perl कार्यान्वयनों का 1:1 पोर्ट होने का प्रयास करता है, और वे सभी एक-दूसरे के साथ पूरी तरह संगत हैं (यानी, वे समान हैश मान उत्पन्न और सत्यापित करते हैं)।

इंटरफ़ेस

प्रत्येक संदर्भ कार्यान्वयन निम्नलिखित छद्म-प्रोटोटाइप वाले दो प्रक्रियात्मक फ़ंक्शन परिभाषित करता है:

string hmac_bcrypt_hash(password, settings?, pepper?)

boolean hmac_bcrypt_verify(password, expected, pepper?)

कृपया इन फ़ंक्शनों को अपने प्रोजेक्ट में एकीकृत करने और उपयोग करने के तरीके के लिए प्रत्येक संदर्भ कार्यान्वयन के साथ दिए गए टेस्ट केस देखें। सरलता के लिए एक प्रक्रियात्मक इंटरफ़ेस चुना गया था, लेकिन आप इन फ़ंक्शनों को अपनी इच्छानुसार कक्षाओं या ऑब्जेक्ट्स में शामिल करने के लिए स्वतंत्र हैं।

इस संदर्भ में settings पैरामीटर एक मानक bcrypt सेटिंग्स स्ट्रिंग को संदर्भित करता है जिसमें हैश पहचानकर्ता (2a), log2 लागत (जैसे, 13), और वैकल्पिक 22-बाइट, radix64-एन्कोडेड सॉल्ट मान (जैसे, LhayLxezLhK1LhWvKxCyLO) होता है। ये मान डॉलर-सीमांकित स्ट्रिंग में एक साथ जोड़े जाते हैं; उदाहरण के लिए, $2a$13$LhayLxezLhK1LhWvKxCyLO।

settings पैरामीटर वैकल्पिक है; अक्सर, डिफ़ॉल्ट लागत 13 और एक जनरेटेड सॉल्ट का उपयोग करने के लिए इसे null/खाली छोड़ दिया जाना चाहिए। अधिक से अधिक, यदि आप 13 के अलावा कोई अन्य लागत मान उपयोग करना चाहते हैं, तो आप केवल id + लागत मान (जैसे, $2a$10$) प्रदान कर सकते हैं। अपने स्वयं के सॉल्ट मान बनाना और प्रदान करना नहीं अनुशंसित है!

pepper पैरामीटर एक वैश्विक साझा गुप्त कुंजी (shared secret) को परिभाषित करता है और यह भी वैकल्पिक है; यदि यह null/खाली है, तो hmac_bcrypt का डिफ़ॉल्ट मान उपयोग किया जाता है। यह मुख्य रूप से शकिंग (shucking) बचाव के लिए है, लेकिन इसका उपयोग क्रैक करने की सुरक्षा, कठिनाई और लागत को बढ़ाने के लिए भी किया जा सकता है (विशेषकर जब HSM के साथ संयोजन में उपयोग किया जाता है)।

एल्गोरिथम विवरण

hmac-bcrypt पासवर्ड हैशिंग फ़ंक्शन उचित प्री-हैशिंग और पोस्ट-हैशिंग के साथ bcrypt का उपयोग करता है, साथ ही एक वैकल्पिक पेपर (pepper) के साथ संयुक्त होता है। स्यूडो कोड में, यह काफी सरल है:

pre_hash  = hmac_sha512_base64(password, pepper)
mid_hash  = bcrypt(pre_hash, settings)
post_hash = hmac_sha512_base64(mid_hash, pepper)

return settings + post_hash

प्री-हैशिंग का उपयोग bcrypt की अधिकतम 72 इनपुट बाइट्स से अधिक इनपुट लंबाई सक्षम करने के लिए किया जाता है। SHA-512 को इसके 64-बिट शब्द आकार के कारण चुना गया था, जो CPU डिफेंडरों के लिए अनुकूल है लेकिन GPU हमलावरों को बाधित करता है। हालाँकि, कई कारणों से कच्चे SHA-512 मान का उपयोग नहीं किया जा सकता है:

1. bcrypt में इनपुट किए गए कच्चे, बिना सॉल्ट वाले हैश मान शकिंग हमलों को सक्षम कर सकते हैं।
2. कुछ bcrypt कार्यान्वयन इनपुट को null-समाप्त cstring के रूप में मानते हैं, जिसके परिणामस्वरूप null बाइट्स वाले हैश मानों के लिए इनपुट छोटा (truncated) हो जाता है।
3. कुछ bcrypt कार्यान्वयन इनपुट को signed char के रूप में मानते हैं और प्रत्येक बाइट के केवल निचले 7 बिट्स का उपयोग करते हैं, जिससे यह बाइनरी इनपुट के लिए अनुपयुक्त हो जाता है।

शकिंग हमलों को कम करने के लिए, प्री-हैश को सॉल्टेड -- या इस मामले में, पेपर्ड -- होना चाहिए, और HMAC हैश को कुंजीबद्ध (keying) करने के लिए एक सुविधाजनक माध्यम प्रदान करता है। परिणामी HMAC मान को फिर base64 के साथ एन्कोड किया जाता है ताकि स्वच्छ, लोअर-ASCII इनपुट तैयार हो सके जो null बाइट्स और बाइनरी डेटा के मुद्दों को कम करता है।

गौर करने वाला पाठक ध्यान देगा कि hmac_sha512_base64 88 बाइट्स डेटा उत्पन्न करता है, जबकि bcrypt की अधिकतम इनपुट आकार 72 बाइट्स है। यह कोई समस्या नहीं है, और वास्तव में sha256 जैसे कम इनपुट डेटा उत्पन्न करने वाले हैश एल्गोरिथम का उपयोग करने पर इसे प्राथमिकता दी जाती है। हम सभी 72 बाइट्स भरना चाहते हैं, और sha512 को 432 बिट्स तक छोटा करने पर कोई सुरक्षा नहीं खोती है (यह sha384 द्वारा प्रदान किए गए 384 बिट्स से अधिक है)।

पोस्ट-हैशिंग का उपयोग मुख्य रूप से hmac-bcrypt हैश को bcrypt हैश से अलग करने के लिए किया जाता है -- यानी, लंबाई अलग होगी -- लेकिन पेपर के कारण सुरक्षा की एक अतिरिक्त परत जोड़ने के लिए भी। पोस्ट-हैशिंग चरण को अतिरिक्त सुरक्षा के लिए HSM में संग्रहीत पेपर मान के साथ भी किया जा सकता है (अत्यधिक अनुशंसित!)

औचित्य

जबकि मेमोरी हार्डनेस एक दिलचस्प प्रयोग रहा है, त्वरण (acceleration) के प्रति प्रतिरोध प्राप्त करने का सही मार्ग स्पष्ट रूप से कैश हार्डनेस है। मेमोरी गति और बैंडविड्थ बढ़ती रहती है, जबकि RAM बड़ी, सस्ती और अधिक सघन होती जाती है। लेकिन कैश आकार, कैश गति और कैश लागत अपेक्षाकृत स्थिर हैं। यहां तक कि हार्डवेयर scatter/gather निर्देशों का भी कैश हार्ड एल्गोरिदम पर वह नाटकीय प्रभाव नहीं पड़ा है जिसकी हमने एक बार भविष्यवाणी की थी।

सर्वोत्तम मेमोरी हार्ड एल्गोरिदम -- Argon2 और scrypt -- वास्तव में 1000ms से कम के लक्ष्य रनटाइम के लिए कैश हार्ड एल्गोरिदम की तुलना में त्वरण के प्रति कम प्रतिरोधी हैं, जिससे वे एक महान KDF बन जाते हैं लेकिन वास्तविक समय के प्रमाणीकरण में महान नहीं होते।

आदर्श रूप से, कोई व्यक्ति जानबूझकर कैश हार्ड पासवर्ड हैशिंग फ़ंक्शन का उपयोग करेगा, जैसे कि pufferfish या bscrypt। हालाँकि, ये फ़ंक्शन नए हैं, कम अध्ययन किए गए हैं, और इनके लिए कुछ ही लाइब्रेरी उपलब्ध हैं। bcrypt, हालांकि -- अनजाने में कैश हार्ड होने के बावजूद -- लगभग हर भाषा और फ्रेमवर्क के लिए आसानी से उपलब्ध है। हमारे पास आसानी से उपलब्ध एल्गोरिदम में से, bcrypt वास्तविक समय, इंटरैक्टिव प्रमाणीकरण (लक्ष्य रनटाइम < 1000ms) के लिए त्वरण के प्रति सबसे अधिक प्रतिरोध प्रदान करता है, इसलिए स्पष्ट उत्तर यह है कि हमारे पास उपलब्ध bcrypt का लाभ उठाया जाए।

हालाँकि, bcrypt में कुछ उल्लेखनीय सीमाएँ हैं, जैसा कि इसके बहुत मुखर आलोचक तुरंत बताते हैं:

1. इसकी कठोर अधिकतम 72 इनपुट बाइट्स है (या कुछ कार्यान्वयनों में कम)
2. कुछ कार्यान्वयन टूटे हुए (broken) हैं

hmac-bcrypt इन दोनों मुद्दों को संबोधित करता है, और भी बहुत कुछ।