प्राधिकरण टोकन सुरक्षित रखें

हाय% उपयोगकर्ता नाम%। रिपोर्ट के विषय के बावजूद, मुझे लगातार सम्मेलनों में एक ही सवाल पूछा जाता है - "उपयोगकर्ता के डिवाइस पर टोकन सुरक्षित रूप से कैसे संग्रहीत करें?"। आमतौर पर मैं जवाब देने की कोशिश करता हूं, लेकिन समय विषय को पूरी तरह से प्रकट करने की अनुमति नहीं देता है। इस लेख के साथ मैं इस मुद्दे को पूरी तरह से बंद करना चाहता हूं।

मैंने दर्जन भर अनुप्रयोगों का विश्लेषण किया कि वे टोकन के साथ कैसे काम करते हैं। संसाधित किए गए महत्वपूर्ण डेटा का विश्लेषण करने वाले सभी अनुप्रयोगों ने मुझे अतिरिक्त सुरक्षा के रूप में इनपुट के लिए एक पिन कोड सेट करने की अनुमति दी। आइए सबसे आम गलतियों को देखें:

• प्रमाणीकरण की पुष्टि करने और नए टोकन प्राप्त करने के लिए RefreshToken के साथ एपीआई में एक पिन कोड भेजना। - खराब, रिफ्रेशटोकन स्थानीय भंडारण में असुरक्षित है, डिवाइस या बैकअप के लिए भौतिक उपयोग के साथ, आप इसे हटा सकते हैं, साथ ही साथ मैलवेयर भी कर सकते हैं।
• मैसेज में पिन कोड को RefreshToken के साथ सेव करना, फिर पिन कोड का लोकल वेरिफिकेशन और RefreshToken को API पर भेजना। - एक बुरा सपना, RefreshToken पिन के साथ असुरक्षित है, जो उन्हें निकालने की अनुमति देता है, इसके अलावा, एक और वेक्टर स्थानीय प्रमाणीकरण को बायपास करने का सुझाव देता है।
• पिन कोड के साथ खराब रीफ्रेशटोकन एन्क्रिप्शन, जो आपको पिन कोड को पुनर्स्थापित करने की अनुमति देता है और सिफरटेक्स्ट से रिफ्रेशटोकन। - पिछली त्रुटि का एक विशेष मामला, थोड़ा और अधिक जटिल शोषण किया। लेकिन ध्यान दें कि यह सही तरीका है।

सामान्य त्रुटियों को देखने के बाद, आप अपने आवेदन में टोकन के सुरक्षित भंडारण के तर्क के माध्यम से सोच सकते हैं। यह आवेदन के संचालन के दौरान प्रमाणीकरण / प्राधिकरण से जुड़ी बुनियादी परिसंपत्तियों के साथ शुरू होने लायक है और उनके लिए कुछ आवश्यकताओं को सामने रखता है:

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

AccessToken - उपयोगकर्ता प्राधिकरण की पुष्टि करने के लिए उपयोग किया जाता है।
+ लंबी अवधि की मेमोरी में कभी संग्रहीत नहीं किया जाता है और केवल रैम में संग्रहीत किया जाता है
+ HTTP अनुरोध के क्वेरी मापदंडों में GET विधि द्वारा प्रेषित नहीं किया जाता है, इसके बजाय POST अनुरोधों का उपयोग किया जाता है

RefreshToken - एक नया AccessToken + RefreshToken बंडल प्राप्त करने के लिए उपयोग किया जाता है।
+ रैम में किसी भी रूप में संग्रहीत नहीं किया जाता है और इसे एपीआई से प्राप्त करने और लंबी अवधि की स्मृति में सहेजने के बाद या दीर्घकालिक मेमोरी और उपयोग से प्राप्त करने के बाद इसे तुरंत हटा दिया जाना चाहिए
+ दीर्घकालिक स्मृति में केवल एन्क्रिप्टेड रूप में संग्रहीत
+ जादू और कुछ नियमों का उपयोग करते हुए एक पिन के साथ एन्क्रिप्ट किया गया (नियमों का वर्णन नीचे किया जाएगा), जिन्हें अगर पिन सेट नहीं किया गया है, तो बिल्कुल भी न सहेजें
+ HTTP अनुरोध के क्वेरी मापदंडों में GET विधि द्वारा प्रेषित नहीं किया जाता है, इसके बजाय POST अनुरोधों का उपयोग किया जाता है

पिन - (आमतौर पर 4 या 6 अंकों की संख्या) - का उपयोग RefreshToken को एन्क्रिप्ट / डिक्रिप्ट करने के लिए किया जाता है।
+ कभी भी डिवाइस पर संग्रहीत नहीं किया जाता है और उपयोग के बाद तुरंत रैम से साफ किया जाना चाहिए
+ कभी भी आवेदन की सीमा नहीं छोड़ता है, वे कहीं भी प्रेषित नहीं होते हैं
+ केवल एन्क्रिप्शन / डिक्रिप्शन RefreshToken के लिए उपयोग किया जाता है

OTP 2FA का एक बार का कोड है।
+ OTP को कभी भी डिवाइस पर संग्रहीत नहीं किया जाता है और इसे एपीआई में भेजने के बाद रैम से तुरंत साफ किया जाना चाहिए
+ HTTP अनुरोध के क्वेरी मापदंडों में GET विधि द्वारा प्रेषित नहीं किया जाता है, इसके बजाय POST अनुरोधों का उपयोग किया जाता है
+ ओटीपी प्रोसेसिंग वाले टेक्स्ट फ़ील्ड के लिए कीबोर्ड कैश अक्षम
+ क्लिपबोर्ड में उन पाठ क्षेत्रों के लिए निष्क्रिय किया गया है जिनमें ओटीपी होता है
+ OTP स्क्रीनशॉट में नहीं मिलता है
+ अनुप्रयोग पृष्ठभूमि पर जाने पर स्क्रीन से ओटीपी निकालता है

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

मैं एक अच्छा उदाहरण दूंगा, मान लीजिए कि हम UUID को एन्क्रिप्ट करना चाहते हैं

aec27f0f-b8a3-43cb-b076-e075a095abfe

AES / CBC / PKCS5Padding के इस सेट के साथ, एक कुंजी के रूप में एक पिन का उपयोग कर। ऐसा लगता है कि एल्गोरिथ्म अच्छा है, सब कुछ दिशानिर्देशों पर आधारित है, लेकिन एक महत्वपूर्ण बिंदु है - कुंजी में बहुत कम एन्ट्रॉपी शामिल है। आइए देखें कि इससे क्या होता है:

1. पैडिंग - चूंकि हमारे टोकन में 36 बाइट्स होते हैं, और एईएस में 128 बिट्स के ब्लॉक के साथ एक ब्लॉक एन्क्रिप्शन मोड होता है, तो एल्गोरिथ्म को टोकन को 48 बाइट्स (जो कि 128 बिट्स की एक बहु है) तक खत्म करने की आवश्यकता होती है। हमारे संस्करण में, पूंछ को PKCS5Padding मानक के अनुसार जोड़ा जाएगा, अर्थात। प्रत्येक बाइट जोड़ा मूल्य बाइट्स बट्टियों की संख्या के बराबर है
   

   01
   ०२ ०२
   03 03 03
   04 04 04 04
   05 05 05 05 05
   06 06 06 06 06 06
   आदि

   हमारा आखिरी ब्लॉक कुछ इस तरह दिखेगा:
   

   ... | 61 62 66 65 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी 0 सी |

   और एक समस्या है, इस पैडिंग को देखते हुए हम गलत कुंजी के साथ डिक्रिप्ट किए गए डेटा (अमान्य अंतिम ब्लॉक द्वारा) को फ़िल्टर कर सकते हैं, और इस प्रकार, मुड़ हीप से मान्य रीफ्रेशटोकन को निर्धारित कर सकते हैं।
2. टोकन का पूर्वनिर्धारित प्रारूप - भले ही हम पैडिंग को जोड़ने से बचने के लिए अपने टोकन को 128 बिट्स (उदाहरण के लिए, हाइफ़न निकालना) के एक से अधिक बनाते हैं, हम निम्नलिखित समस्या में आएंगे। समस्या यह है कि एक ही मुड़ के सभी हम लाइनों को इकट्ठा कर सकते हैं और निर्धारित कर सकते हैं कि कौन से यूयूआईडी प्रारूप के तहत आता है। अपने विहित पाठ रूप में UUID हेक्साडेसिमल प्रारूप में 32 अंक 5 समूहों 8-4-4-4-12 में एक हाइफ़न द्वारा अलग किया गया है
   XXXXXXXXXXXX-Mxxx-Nxxx-XXXXXXXXXXXX
   जहाँ M संस्करण है और N विकल्प है। यह सब गलत कुंजी के साथ डिक्रिप्ट किए गए टोकन को छानने के लिए पर्याप्त है, एक उपयुक्त यूयूआईडी रिफ्रेशटोकन प्रारूप को छोड़कर।

उपरोक्त सभी को देखते हुए, आप कार्यान्वयन के लिए आगे बढ़ सकते हैं, मैंने 64 यादृच्छिक बाइट्स उत्पन्न करने और उन्हें बेस 64 में लपेटने के लिए एक सरल विकल्प चुना:

public String createRefreshToken() { byte[] refreshToken = new byte[64]; final SecureRandom secureRandom = new SecureRandom(); secureRandom.nextBytes(refreshToken); return Base64.getUrlEncoder().withoutPadding() .encodeToString(refreshToken); } 

यहाँ इस तरह के एक टोकन का एक उदाहरण है:

YmI8rF9pwB1KjJAZKY9JzqsCu3kFz4xt4GkRCzXS9-FS_kbN3-CF9RGiRuuGqwqMo-VxFDhgQNmgjlQFD2GvbA

अब देखते हैं कि यह एल्गोरिदम कैसे दिखता है (एंड्रॉइड और आईओएस पर एल्गोरिदम समान होगा):

 private static final String ALGORITHM = "AES"; private static final String CIPHER_SUITE = "AES/CBC/NoPadding"; private static final int AES_KEY_SIZE = 16; private static final int AES_BLOCK_SIZE = 16; public String encryptToken(String token, String pin) { decodedToken = decodeToken(token); //   rawPin = pin.getBytes(); byte[] iv = generate(AES_BLOCK_SIZE); //      CBC byte[] salt = generate(AES_KEY_SIZE); //       byte[] key = kdf.deriveKey(rawPin, salt, AES_KEY_SIZE); //  -    Cipher cipher = Cipher.getInstance(CIPHER_SUITE); //    cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, ALGORITHM), new IvParameterSpec(iv)); return cipher.doFinal(token); } public byte[] decodeToken(String token) { byte[] rawToken = token.getBytes(); return Base64.getUrlDecoder().decode(rawToken); } public final byte[] generate(int size) { byte[] random = new byte[size]; (new SecureRandom()).nextBytes(random); return random; } 

किन लाइनों पर ध्यान देने योग्य है:

 private static final String CIPHER_SUITE = "AES/CBC/NoPadding"; 

कोई पैडिंग नहीं, ठीक है, आपको याद है।

 decodedToken = decodeToken(token); //   

आप बेस 64 प्रतिनिधित्व में एक टोकन को केवल ले और एन्क्रिप्ट नहीं कर सकते हैं, क्योंकि इस प्रतिनिधित्व का एक निश्चित प्रारूप है (ठीक है, आपको याद है)।

 byte[] key = kdf.deriveKey(rawPin, salt, AES_KEY_SIZE); //  -    

आउटपुट पर, हमें AES_KEY_SIZE आकार की एक कुंजी मिलती है, जो AES एल्गोरिथ्म के लिए उपयुक्त है। Argon2, SHA-3, Scrypt द्वारा सुझाए गए किसी भी महत्वपूर्ण व्युत्पत्ति समारोह का उपयोग खराब जीवन pbkdf2 के मामले में kdf के रूप में किया जा सकता है (यह FPGA पर बहुत अच्छी तरह से समानता रखता है)।

अंतिम एन्क्रिप्ट किए गए टोकन को डिवाइस पर सुरक्षित रूप से संग्रहीत किया जा सकता है और चिंता न करें कि कोई इसे चुरा सकता है, यह एक मैलवेयर या एक इकाई है जिसे नैतिक सिद्धांतों द्वारा नहीं तौला जाता है।

कुछ और सिफारिशें:

• बैकअप से टोकन निकाल दें।
• IOS पर, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly विशेषता के साथ किचेन में टोकन स्टोर करें।
• आवेदन के दौरान इस लेख (कुंजी, पिन, पासवर्ड, आदि) में चर्चा की गई संपत्तियों को तितर बितर न करें।
• अनावश्यक रूप से जैसे ही संपत्ति को अधिलेखित करें, उन्हें अपनी स्मृति में आवश्यकता से अधिक समय तक न रखें।
• एंड्रॉइड पर सिक्योर रैंडम का उपयोग करें और क्रिप्टोग्राफिक संदर्भ में रैंडम बाइट्स उत्पन्न करने के लिए iOS पर SecRandomCopyBytes।

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

संदर्भ:

CWE-311: सेंसिटिव डेटा की गुम एन्क्रिप्शन
CWE-327: ब्रोकन या रिस्की क्रिप्टोग्राफ़िक एल्गोरिथम का उपयोग
CWE-327: CWE-338: क्रिप्टोग्राफिक रूप से कमजोर छद्म यादृच्छिक संख्या जनरेटर (PRNG) का उपयोग
CWE-598: GET रिक्वेस्ट में क्वेरी स्ट्रिंग्स के माध्यम से सूचना एक्सपोजर