लिनक्स में स्पष्ट पाठ के रूप में उपयोगकर्ता के पासवर्ड को कैसे दिखाया जाए?

Question

हम जानते हैं कि उपयोगकर्ताओं के पासवर्ड सहेजे जाते हैं /etc/passwd, लेकिन एन्क्रिप्टेड तरीके से, इसलिए रूट भी उन्हें नहीं देख सकते हैं:

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

जैसा कि ऊपर दिखाया गया है, :x:पासवर्ड का प्रतिनिधित्व करता है।

क्या /etc/passwdस्पष्ट पाठ में पासवर्ड को सहेजने का एक तरीका (संभव कॉन्फ़िगरेशन) है और ऐसा है कि रूट उन्हें देख सकता है?

Comments

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

— हेलोजोस्ट

मैं इस बारे में उत्सुक हूं, सिस्टम का एडमिन (रूट) अन्य उपयोगकर्ताओं के पासवर्ड क्यों नहीं देख सकता है?

— user78050

@ user78050 क्योंकि रूट उपयोगकर्ता के पास अन्य उपयोगकर्ताओं के पासवर्ड को जानने का कोई कारण नहीं है, और ऐसा करने के लिए उन्हें अनुमति देना एक बड़ा सुरक्षा जोखिम होगा।

— डेविड जेड

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

— HalosGhost

MD5 "एन्क्रिप्शन विधि" का उपयोग करें फिर इंद्रधनुष तालिकाओं का उपयोग करके पासवर्ड को क्रैक करें ।

— क्रिस्टियन सियुपिटु

Answer 1

अन्य दो जवाबों ने आपको सही-सही बताया है! -यह एक खराब आइडिया है । लेकिन उन्होंने कार्यक्रमों के एक समूह को बदलने के लिए आपको अपनी मेहनत करने के लिए भी कहा है ।

यह सच नहीं है। यह बहुत आसान है। आपको केवल एक या दो कॉन्फ़िगरेशन फ़ाइलों को बदलने की आवश्यकता है। मुझे यह इंगित करना महत्वपूर्ण लगता है, क्योंकि आपको उन प्रणालियों के बारे में पता होना चाहिए जब आप उन प्रणालियों में प्रवेश करते हैं जिन्हें आप नियंत्रित नहीं करते हैं। ये वास्तव में एक सादा-पाठ पासवर्ड नहीं डालेंगे /etc/passwdया /etc/shadow, यह एक अलग फ़ाइल में जाएगा। ध्यान दें कि मैंने इनका परीक्षण नहीं किया है, क्योंकि मैं सादे पाठ में अपना पासवर्ड नहीं रखता।

1. संपादित करें /etc/pam.d/common-password(पासवर्ड परिवर्तित /etc/pam.d/common-authकरने के लिए पकड़ने के लिए ) या (लॉगिन पर पकड़ने के लिए) और जोड़ें… pam_exec expose_authtok log=/root/passwords /bin/cat

2. उन दोनों को संपादित करें, और pam_unix से pam_userdb पर स्विच करें crypt=none। वैकल्पिक रूप से, आप इसे केवल पासवर्ड-पासवर्ड (pam_unix को छोड़कर) को केवल पासवर्ड रिकॉर्ड करने के लिए रख सकते हैं जब वे बदले जाते हैं।

3. आप shadowछाया फ़ाइल को अक्षम करने के लिए pam_unix से (और साथ ही किसी भी मजबूत हैश विकल्प) विकल्प को हटा सकते हैं, और पारंपरिक क्रिप्ट पासवर्ड पर वापस जा सकते हैं। सादा पाठ नहीं, लेकिन जॉन द रिपर आपके लिए यही तय करेगा।

अधिक जानकारी के लिए, PAM सिस्टम एडमिन गाइड की जाँच करें ।

आप PAM के स्रोत कोड को भी संपादित कर सकते हैं, या अपना खुद का मॉड्यूल लिख सकते हैं। आपको केवल PAM (या आपके मॉड्यूल) को संकलित करने की आवश्यकता होगी, और कुछ नहीं।

Comments

मुझे लगता है कि सादा पाठ पासवर्ड लिखे जाते हैं /root/passwords।

— फहीम मीठा

Btw। यह जानना बहुत अच्छा है कि यह कितना आसान है और मुझे एक समझौता प्रणाली से डरना होगा।

— एरिक

@erik यह पूछने वाले का विशेषाधिकार है कि वह जो भी उत्तर देना चाहता है, वह स्वीकृत उत्तर के रूप में सबसे अधिक उपयोगी है। यह शायद एक अच्छी बात है कि ओपी ने पाया "ऐसा मत करो!" सबसे उपयोगी ... इसके अलावा, स्पष्ट होने के लिए, यह एक समझौता या दुर्भावनापूर्ण रूप से प्रशासित सिस्टम पर पासवर्ड चोरी करने का एकमात्र तरीका नहीं है। इसलिए आप सुरक्षित रहने के लिए PAM कॉन्‍फ़िगर को नहीं देख सकते।

— जुलाब

इसके बजाय यह माना जाता है कि डिस्ट्रो पैम का उपयोग कर रहा है, किसी भी तरह से सभी ऐसा नहीं करते हैं।

— वैधता

@msw मैंने उत्तर दिया क्योंकि इसकी स्पष्ट रूप से एक आम धारणा है कि स्पष्ट पाठ पासवर्ड के साथ लिनक्स बॉक्स चलाना कठिन है (बॉबी ने अपने क्रेडिट के लिए, अपना उत्तर निर्धारित किया; एंथन का अभी भी यह कठिन लगता है)। यह एक खतरनाक विश्वास है, क्योंकि यह पासवर्ड पुनः उपयोग को प्रोत्साहित करता है। अगर मैंने सिर्फ एक उत्तर "वास्तव में, इसका आसान पोस्ट किया है, तो आप एक या दो फ़ाइल संपादित करते हैं, लेकिन मैं आपको नहीं बताऊंगा" तो किसी ने भी ऐसा नहीं माना होगा। मुझे (उस समय) अधिक उच्च मतदान, अधिक गहन जवाबों के बारे में क्यों सुना? बिंदु बनाने के लिए यह कहने की आवश्यकता है कि यह कैसे करना है। (हालांकि, वे उदाहरणों की नकल और पेस्ट नहीं कर रहे हैं। सोचा अभी भी उपयोग करने की आवश्यकता है।)

— 15:31

Answer 2

हे प्रिय, ठीक है, चलो शुरू में ही शुरू करते हैं ...

हम जानते हैं कि उपयोगकर्ताओं के पासवर्ड / etc / passwd में सहेजे जाते हैं, लेकिन एन्क्रिप्टेड तरीके से

नहीं, वे में संग्रहीत किए गए हैं /etc/passwd, और यह कुछ समय पहले था। आज पासवर्ड को एक तथाकथित छाया फ़ाइल में संग्रहीत किया जाता है , अधिकांश समय /etc/shadow।

लेकिन एक एन्क्रिप्टेड तरीके से, इसलिए रूट भी उन्हें नहीं देख सकता है:

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

छाया फ़ाइल में पासवर्ड को हैश के रूप में संग्रहीत किया जाता है।

जैसा कि ऊपर दिखाया गया है: x: पासवर्ड का प्रतिनिधित्व करते हैं

xइस मामले में केवल विरासत पासवर्ड क्षेत्र के लिए एक प्लेसहोल्डर है। इसका xमतलब है कि पासवर्ड को छाया फ़ाइल में पाया जा सकता है।

क्या स्पष्ट पाठ में / etc / passwd में पासवर्ड सहेजने का कोई तरीका (संभावित कॉन्फ़िगरेशन) है और ऐसा है कि रूट उन्हें देख सकता है?

हां, यह वास्तव में संभव है, लेकिन कुछ कारणों से यह एक अच्छा विचार नहीं है। Derobert का जवाब इसे करने का एक सरल तरीका बताता है ।

लेकिन यह एक अच्छा विचार क्यों नहीं है? ठीक है, एक सरल लेकिन बहुत महत्वपूर्ण कारण के लिए: सुरक्षा। मैं इन सवालों को पढ़ने का सुझाव देता हूं:

• यह समझाने के लिए एक अच्छा सादृश्य क्या है कि पासवर्ड एक आम आदमी को क्यों भेजा जाना चाहिए?
• हैश पासवर्ड कैसे सुरक्षित करें?
• मेरे पास पासवर्ड क्यों होना चाहिए?
• पासवर्ड हैशिंग को इतना महत्वपूर्ण क्यों माना जाता है?
• हैश फ़ंक्शन एक तरह से क्यों हैं? अगर मुझे एल्गोरिथ्म पता है, तो मैं इससे इनपुट की गणना क्यों नहीं कर सकता हूं?

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

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

Comments

एन्क्रिप्शन और हैशिंग के बारे में ओपी के बचाव में, glibc का क्रिप्ट मैन पेज कहता है: «यदि नमक एक कैरेक्टर स्ट्रिंग है जिसे कैरेक्टर्स स्ट्रिंग से शुरू करते हैं, "$id$"उसके बाद एक स्ट्रिंग समाप्त हो जाती है "$": $id$salt$encrypted तो DES मशीन का उपयोग करने के बजाय, उपयोग की idगई एन्क्रिप्शन विधि की पहचान करता है और फिर यह निर्धारित करता है कि स्ट्रिंग के बाकी हिस्सों की व्याख्या कैसे की जाती है »।

— क्रिस्टियन सियुपिटु

दिलचस्प है, लेकिन मुख्य सवाल का जवाब नहीं है, जैसा कि derobert का जवाब है।

— एरिक

@ कभी-कभी किसी प्रश्न का सही उत्तर "यह मत करो" है, तब भी जब तकनीकी रूप से यह संभव है। यह उस काल में से एक है।

— गिल्स एसओ- बुराई को रोकना '

मैं इस लाइन को बदलने का सुझाव देता हूं: "नहीं, कई एप्लिकेशन और उनके काम करने के तरीके को छोड़कर कोई रास्ता नहीं है।" यह धारणा छोड़ देता है कि यह आसान नहीं है (या कार्यात्मक रूप से कुछ करने के लिए कम से कम आसान है)।

— जुलाब

@ बॉबी यह एक उत्कृष्ट प्रतिक्रिया है, लेकिन एक उत्कृष्ट उत्तर नहीं है। इसे एक उत्कृष्ट उत्तर बनाने के लिए, आपको इसके बारे में भाग को "आसानी से संभव नहीं" होने के लिए बदलना चाहिए, क्योंकि यह स्पष्ट रूप से है, जैसा कि व्युत्पन्न के उत्तर में दिखाया गया है।

— माइकल डोरस्ट

Answer 3

सबसे पहले एन्क्रिप्टेड पासवर्ड में नहीं हैं /etc/passwd, लेकिन वे अंदर हैं /etc/shadow। इसका एक कारण यह है कि /etc/passwdसार्वजनिक रूप से पठनीय है (इसलिए आप किसी अन्य उपयोगकर्ता के लिए GECOS फ़ील्ड जानकारी पा सकते हैं), और, विशेष रूप से पुरानी एन्क्रिप्शन योजनाओं के साथ एन्क्रिप्टेड पासवर्ड के खिलाफ क्रूर बल के हमलों की अनुमति दे सकते हैं।

पासवर्ड को केवल सादे पाठ में संग्रहीत करने के लिए, आवश्यक नहीं है और /etc/shadowमान्य पासवर्ड की जांच करने के लिए जानकारी को पढ़ने वाले पासवर्ड प्रोग्राम और पुस्तकालयों को अपडेट की आवश्यकता होगी । और फिर आपको यह उम्मीद करनी होगी कि सभी उपयोगिताओं साझा पुस्तकालयों का उपयोग उस जानकारी को एक्सेस करने के बजाय सांख्यिकीय रूप से किसी ऐसी चीज के खिलाफ जुड़े हुए हैं जो सादा पासवर्ड स्टोरेज को नहीं समझती है।

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

इसके अलावा, लोग एक ही या समान पासवर्ड का कई सिस्टमों पर उपयोग करते हैं, इसलिए किसी भी पासवर्ड का मानव के लिए उचित होना अच्छा नहीं है। जैसा कि कुछ sysadmin अन्य प्रणालियों (ओं) पर अपना पुन: प्रयास कर सकता है, वह जानता है कि उपयोगकर्ता के पास एक खाता है।

अधिक दिलचस्प चीजें होनी चाहिए, आपके सिस्टम पर कामकाज की जांच की जा सकती है।

Comments

/etc/shadowएन्क्रिप्टेड पासवर्ड को स्टोर नहीं करता है, यह पासवर्ड हैश को स्टोर करता है। हां, फ़ंक्शन को कहा जाता है crypt, और मैन पेज "एन्क्रिप्टेड" कहता है, लेकिन अगर आप एक मछली को साइकिल कहते हैं, तो यह पहियों को नहीं देता है। ध्यान दें कि /etc/shadowकिसी भी प्रोग्राम (कम से कम लिनक्स और सोलारिस पर) को दोबारा स्थापित किए बिना स्टोर पासवर्ड को एक अलग प्रारूप में बनाना संभव होगा : प्रमाणीकरण विधियां हमेशा गतिशील रूप से जुड़ी होती हैं। सादे पाठ के रूप में पासवर्ड संग्रहीत करना एक भयानक विचार होगा लेकिन काम के एक बिट के साथ संभव है ।

— गिल्स एसओ- बुराई को रोकना '

@ मैं केवल ओपी शब्दावली का पुन: उपयोग करता हूं, लेकिन आप सही हैं कि हैश अधिक उपयुक्त शब्द है।

— एंथन जूल

Answer 4

मूल कारण (यह एक बुरा विचार क्यों है) यह है कि किसी भी उपयोगकर्ता (रूट, व्यवस्थापक या अन्य) को कभी भी दूसरे के उपयोगकर्ता पासवर्ड तक पहुंच नहीं होनी चाहिए।

केवल इसलिए कि पासवर्ड प्रमाणीकरण का एक साधन है। यदि मुझे किसी अन्य उपयोगकर्ता का पासवर्ड पता है, तो मुझे उनकी साख (उपयोगकर्ता नाम + पासवर्ड) पता है, इसलिए मैं उस उपयोगकर्ता के रूप में लॉगिन कर सकता हूं , उसे (या उसे) प्रतिरूपित कर रहा हूं।

जब भी मैं उस उपयोगकर्ता के रूप में लॉग इन करता हूं, तो अन्य उपयोगकर्ता को इसके लिए जिम्मेदार माना जाएगा। और यह नहीं है कि प्रमाणीकरण कैसे काम करना चाहिए।

कार्य विनाशकारी हो सकते हैं, जैसे महत्वपूर्ण फाइलों का एक पूरा गुच्छा हटाना, हार्ड डिस्क को मिटाना, बैकअप को मिटाना, परमाणु ऊर्जा योजनाओं को बंद करना आदि।

या सिर्फ अवैध है। एक बैंक संस्थान की कल्पना करें जहां मैं (व्यवस्थापक) सभी पासवर्डों तक पहुंच रखता हूं। कैशियर के पासवर्ड का उपयोग करके मैं राष्ट्रपति के बैंक खाते से विंडो क्लीनर के बैंक खाते में एक मिलियन डॉलर की चाल का आदेश दे सकता हूं। फिर लेनदेन को अनुमोदित करने के लिए खजांची के बेहतर पासवर्ड का उपयोग करें। फिर विंडो क्लीनर के खाते से मेरे स्वयं के किनारे के बैंक खाते में एक चेक को अनुमोदित करें।

तब मैं बहामास में लंबी छुट्टी पर जाता हूं ...

---

उस दृश्य में, पासवर्ड के हैशिंग और अलग-अलग छाया फ़ाइलों के उपयोग को इस नियम को लागू करने के लिए एक साधन के रूप में देखा जा सकता है (कोई उपयोगकर्ता किसी अन्य को लागू करने में सक्षम नहीं होना चाहिए)।

और जैसा कि @ मिरल ने टिप्पणी की ^* , इसमें अपवाद है su(जबकि ऊपर दिए गए तर्क को प्रतिरूपण के प्रकार और फेंकता है) की अनुमति भी है, इसके उपयोग का एक लॉग भी रख रहा है (इसलिए यह नियमों को "केवल व्यवस्थापक ही बदल सकता है" लेकिन लॉग रखा गया है ")।

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

Comments

इस तर्क के साथ एक दोष यह है कि रूट उपयोगकर्ता सिस्टम पर किसी अन्य उपयोगकर्ता को वैसे भी लागू कर सकता है, बिना उनका पासवर्ड जाने। जितना आसान su otheruser।

— मिरल

@ मिरल तुम सही हो, मैंने इस पर विचार नहीं किया। और यद्यपि suलॉग इन का उपयोग किया जाता है, सु कोई उपयोगकर्ता वास्तव में क्या करता है, इसका रिकॉर्ड नहीं रखता है जबकि एक उपयोगकर्ता किसी अन्य को लागू करता है। और एक दुर्भावनापूर्ण जड़ हमेशा भविष्य के जांचकर्ताओं से कार्यों को छिपाने के लिए लॉग को बदल सकती है।

— ypercube y