UUID.randomUUID() एक बार पासवर्ड के रूप में उपयोग के लिए उपयुक्त है?

Question

previous discussed के रूप में, पुष्टिकरण ईमेल में एक अद्वितीय, (व्यावहारिक रूप से) अनुमान लगाने योग्य कोड होना चाहिए - अनिवार्य रूप से one-time password - पुष्टिकरण लिंक में।

The UUID.randomUUID() docs कहते हैं:

UUID एक को क्रिप्टोग्राफी मजबूत छद्म यादृच्छिक संख्या जनरेटर का उपयोग कर उत्पन्न होता है।

क्या यह दर्शाता है कि यूयूआईडी यादृच्छिक जनरेटर एक उचित ढंग से कार्यान्वित जेवीएम में अद्वितीय, (व्यावहारिक रूप से) अनुमान लगाने योग्य ओटीपी के रूप में उपयोग के लिए उपयुक्त है?

Answer 1

संUUID spec के अनुसार:

यह मानकर न चलें कि UUIDs का अनुमान लगाना मुश्किल है, उन्हें सुरक्षा क्षमताओं के रूप में उपयोग नहीं किया जाना चाहिए (पहचानकर्ता जिनके पास केवल पहुंच प्रदान करता है), उदाहरण के लिए। एक अनुमानित यादृच्छिक संख्या स्रोत स्थिति को बढ़ा देगा।

इसके अलावा, यूयूआईडी में केवल 16 संभावित वर्ण (एफ के माध्यम से 0) हैं। आप SecureRandom (@erickson के लिए धन्यवाद) का उपयोग करके अधिक कॉम्पैक्ट और स्पष्ट रूप से सुरक्षित यादृच्छिक पासवर्ड उत्पन्न कर सकते हैं।

import java.security.SecureRandom; 
import java.math.BigInteger; 

public final class PasswordGenerator { 
    private SecureRandom random = new SecureRandom(); 

    public String nextPassword() { 
     return new BigInteger(130, random).toString(32); 
    } 
} 

Answer 2

मुझे लगता है कि यह उपयुक्त होना चाहिए, क्योंकि यह किसी भी विशिष्ट इनपुट (यानी आप इसे उपयोगकर्ता नाम या कुछ ऐसा नहीं कर रहे हैं) के बजाय यादृच्छिक रूप से उत्पन्न होता है - इसलिए इस कोड के लिए कई कॉल अलग-अलग परिणाम देंगे। यह कहता है कि इसकी एक 128-बिट कुंजी है, इसलिए इसे तोड़ने के लिए अव्यवहारिक होना काफी लंबा है।

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

Answer 3

यह एक बार पासवर्ड के रूप में एकदम सही है, क्योंकि मैंने इसे लागू करने के लिए भी आवेदन किया था जिस पर मैं काम कर रहा हूं। इसके अलावा, जो लिंक आपने साझा किया है वह सब कुछ कहता है।

Answer 4

यदि यह एक सीएसआरएनजी द्वारा उत्पन्न होता है तो यह अप्रत्याशित है और इसलिए इसका उपयोग किया जा सकता है।

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

यूयूआईडी भी लंबे तार हैं (128-बिट्स आमतौर पर बेस 64 (22 वर्ण) या बेस 16-एन्कोडेड (32 वर्ण)) - इस बारे में सोचें कि आपका सिस्टम उपयोगकर्ता के अनुकूल कैसे होगा। व्यक्तिगत रूप से मैं यादृच्छिक रूप से 8 अल्फान्यूमेरिक वर्णों का चयन करने के लिए एक CSRNG का उपयोग करता हूं और उन्हें वापस कर देता हूं।

Answer 5

एक पुष्टिकरण लिंक के लिए यादृच्छिक कोड का बिंदु यह है कि हमलावर अनुमान लगाने और मूल्य की भविष्यवाणी करने में सक्षम नहीं होना चाहिए। जैसा कि आप देख सकते हैं, अपने पुष्टिकरण लिंक पर सही कोड ढूंढने के लिए, 128 बिट्स लंबाई यूयूआईडी 2^128 अलग-अलग संभावित कोड, अर्थात् 340,282,366,920,938,463,463,374,607,431,768,211,456 संभव कोड को आज़माएं। मुझे लगता है कि आपका पुष्टिकरण लिंक परमाणु हथियार लॉन्च करने के लिए नहीं है, है ना? हमलावर अनुमान लगाने के लिए यह मुश्किल है। यह सुरक्षित है।

- अद्यतन -

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

कोड = SHA1 (UUID, प्रक्रिया पीआईडी, थ्रेड ID, स्थानीय कनेक्शन पोर्ट संख्या, सीपीयू तापमान)

यह और भी कठिन भविष्यवाणी करने के लिए बनाते हैं।

Answer 6

अगर आप RFC कि UUIDs परिभाषित करता है, और जो एपीआई डॉक्स से लिंक किया गया पढ़ते हैं, आपको लगता है कि नहीं UUID के सभी बिट्स वास्तव में यादृच्छिक हैं ("संस्करण" और "संस्करण" दिखाई देगा यादृच्छिक नहीं हैं)। तो एक प्रकार 4 यूयूआईडी (जिस तरह से आप उपयोग करना चाहते हैं), अगर सही ढंग से कार्यान्वित किया गया है, तो 128 बिट्स के कुल आकार में, 122 बिट्स (सुरक्षित, इस कार्यान्वयन के लिए) यादृच्छिक जानकारी होनी चाहिए।

तो हाँ, यह एक "सुरक्षित" जनरेटर से 122 बिट यादृच्छिक संख्या के साथ-साथ काम करेगा। लेकिन एक छोटे मूल्य में पर्याप्त मात्रा में यादृच्छिकता हो सकती है और उपयोगकर्ता के लिए यह आसान हो सकता है (शायद मैं एकमात्र पुराना शैली वाला व्यक्ति हूं जो अभी भी टर्मिनल में ईमेल पढ़ता है, लेकिन लाइनों में लपेटने वाले पुष्टिकरण URL परेशान हैं ... ।)।

Answer 7

हां, java.util.UUID का उपयोग करना ठीक है। ऐसा करने की जरूरत नहीं है।

यहाँ मेरी सुझाव है:

1. यूआरएल तर्क के रूप में यह में एक विशाल पासवर्ड के साथ एक लिंक भेज देते हैं।
2. उपयोगकर्ता लिंक क्लिक करता है, अपने बैकएंड लिखने इतना है कि यह तय करेंगे या नहीं, तर्क सही है और उपयोगकर्ता के प्रवेश कि।
3. UUID अमान्य 24 घंटे के बाद इसे जारी किया गया है।

यह कुछ काम करेगा, लेकिन यदि आप वास्तव में एक मजबूत, सुरक्षित प्रणाली लिखने की परवाह करते हैं तो यह आवश्यक है।