क्या किसी भी कमांड के लिए प्रॉम्प्ट का उपयोग करके संवेदनशील डेटा को पास करने का एक तरीका है?

40

मान लीजिए कि मैं sha1passकमांड लाइन पर कुछ संवेदनशील पासवर्ड का हैश उत्पन्न करने के लिए उपयोग कर रहा था। मैं sha1pass mysecretएक हैश उत्पन्न करने के लिए उपयोग कर सकता हूं , mysecretलेकिन इसका नुकसान यह mysecretहै कि अब बैश इतिहास में है। क्या इस दिशा के अंतिम लक्ष्य को पूरा करने का एक तरीका है, जबकि mysecretसादे पाठ में प्रकट होने से बचना , शायद passwd-स्टाइल प्रॉम्प्ट का उपयोग करके ?

मैं किसी भी आदेश के प्रति संवेदनशील डेटा पास करने के लिए ऐसा करने के लिए एक सामान्यीकृत तरीके से दिलचस्पी रखता हूं। जब संवेदनशील डेटा एक तर्क (जैसे sha1pass) में या एसटीडीआईएन पर कुछ कमांड में पारित किया जाता है तो विधि बदल जाएगी ।

क्या इसको मदद देने का कोई तरीका है?

संपादित करें : इस सवाल ने बहुत ध्यान आकर्षित किया और नीचे दिए गए कई अच्छे उत्तर दिए गए हैं। एक सारांश है:

के अनुसार @ Kusalananda का जवाब , आदर्श एक एक पासवर्ड या एक उपयोगिता के लिए एक कमांड लाइन तर्क के रूप में गुप्त देने के लिए कभी नहीं होगा। यह कई मायनों में उसके द्वारा वर्णित के रूप में असुरक्षित है, और एक को एक बेहतर डिज़ाइन की गई उपयोगिता का उपयोग करना चाहिए जो STININ के गुप्त इनपुट को लेने में सक्षम है
@ vfbsilva का उत्तर बताता है कि चीजों को बैश इतिहास में संग्रहीत करने से कैसे रोका जाए
@ जोनाथन के जवाब में इसे पूरा करने के लिए पूरी तरह से अच्छी विधि का वर्णन किया गया है जब तक कि कार्यक्रम एसटीडीआईएन पर अपने गुप्त डेटा को ले सकता है। जैसे, मैंने इस उत्तर को स्वीकार करने का फैसला किया है। sha1passमेरे ओपी में केवल एक उदाहरण था, लेकिन चर्चा ने स्थापित किया है कि बेहतर उपकरण मौजूद हैं जो एसटीडीआईएन पर डेटा लेते हैं।
@R के रूप में .. उनके उत्तर में नोट्स , एक चर पर कमांड विस्तार का उपयोग सुरक्षित नहीं है ।

इसलिए, संक्षेप में, मैंने @ जोनाथन के उत्तर को स्वीकार कर लिया है क्योंकि यह सबसे अच्छा समाधान है कि आपके पास काम करने के लिए एक अच्छी तरह से डिजाइन और अच्छी तरह से व्यवहार किया गया कार्यक्रम है। यद्यपि कमांड-लाइन तर्क के रूप में एक पासवर्ड या गुप्त गुजरना मौलिक रूप से असुरक्षित है, अन्य उत्तर सरल सुरक्षा चिंताओं को कम करने के तरीके प्रदान करते हैं।

shell security password

— cemulate
स्रोत

6

इतना ही नहीं: चल रही प्रक्रियाओं को सूचीबद्ध करने की अनुमति के साथ एक ही मशीन पर कोई भी संभावित रूप से देख सकता है कि sha1pass mysecretचल रहा है, और इसलिए पता है कि क्या mysecretहै। (यह केवल कुछ सेकंड के लिए काम करता है, जबकि कार्यक्रम वास्तव में चल रहा है, निश्चित रूप से ...)

— मैथमैटिकलऑर्चिड

@ मैमेटेमिकलऑर्चिड को एक निजी वर्चुअल मशीन में चलाकर इससे बचा जा सकता है। लेकिन यह है कि केवल एक ही पासवर्ड उत्पन्न करने के लिए स्थापित करने के लिए बहुत ज्यादा काम हो सकता है ... :-)

— Kusalananda

5

@Kusalananda मेरे बिंदु अधिक "कभी कमांड लाइन पर संवेदनशील डेटा डाल नहीं है, भले ही आप यह पता लगाने कैसे बंद आदेश इतिहास चालू करने के लिए" था ...

— MathematicalOrchid

2

जैसा कि आप जानते हैं, SHA-1 अभी कुछ वर्षों से कुंजी या पासवर्ड हैश के लिए पदावनत है।

— डेविड फ़ॉस्टर

2

ध्यान दें कि यदि सिस्टम एक ऑडिट डेमॉन चला रहा है, तो सभी कमांड और सभी उपयोगकर्ताओं के सभी तर्क रूट द्वारा केंद्रीय रूप से लॉग इन किए जाते हैं, इसलिए जो कोई भी उन लॉग तक पहुंच सकता है, वह इसे देखेगा।

— रान्डेल

20

यदि zshया bashशेल का उपयोग करते हैं, readतो टर्मिनल डिवाइस से एक लाइन को पढ़ने के लिए शेल गूंज के लिए -s विकल्प का उपयोग करें, इसके बिना यह गूंज रहा है।

IFS= read -rs VARIABLE < /dev/tty

तब आप चर के रूप में चर का उपयोग करने के लिए कुछ फैंसी पुनर्निर्देशन का उपयोग कर सकते हैं।

sha1pass <<<"$VARIABLE"

अगर कोई चलाता है ps, तो वे सब देखेंगे "sha1pass"।

sha1passजब कोई तर्क नहीं दिया जाता है, तो यह माना जाता है कि स्टडिन से पासवर्ड पढ़ता है (एक लाइन पर, लाइन सीमांकक को अनदेखा करता है)।

— जोनाथन
स्रोत

मेरा मानना है कि हमने स्थापित किया है कि sha1passइसके मानक इनपुट स्ट्रीम का उपयोग नहीं करता है।

— Kusalananda

@ कुसलानंद ठीक है, लेकिन यह विधि उन कार्यक्रमों के लिए काम करेगी जो स्टड से पढ़ते हैं।

— जोनाथन

तो, यह मानते हुए कि उपयोगिता एसटीडीआईएन पर अपना गुप्त इनपुट ले सकती है, यह एक ध्वनि और सुरक्षित समाधान है, सुरक्षा-वार?

— cemulate

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

— २४'१ c

1

@cemulate, ... कमांड लाइन पर सुरक्षित नहीं । एक वंशानुगत या हेरिंगिंग के संदर्भ में (जैसा कि यहां उत्तर में है), यह उजागर नहीं है ps, लेकिन एक अस्थायी फ़ाइल को लिखा जा सकता है - अगर कोई इससे बचना चाहता है, तो sshpass < <(printf '%s\n' "$VARIABLE")माना जा सकता है (क्योंकि printfएक बिलिन है, न कि एक बाहरी आदेश, इसे पास नहीं किया गया है execvऔर इसके माध्यम से पहुँचा जा सकता है ps)।

— चार्ल्स डफी

35

आदर्श रूप में, आप कमांड लाइन पर एक कमांड के तर्क के रूप में एक स्पष्ट-टेक्स्ट पासवर्ड कभी नहीं टाइप करते हैं। ऐसा करने से पासवर्ड कमांड के लिए एक तर्क हो जाता है, और कमांड लाइन की दलीलें प्रक्रिया तालिका में सरल उपकरण जैसे psकुछ ऑडिट लॉग में लॉग इन या लॉग इन करके देखी जा सकती हैं ।

यह कहने के बाद, शेल के कमांड इतिहास से वास्तविक पासवर्ड को छिपाने के तरीके निश्चित रूप से हैं।

sha1pass "$( head -n 1 )"

फिर पासवर्ड टाइप करें और दबाएं Enter। headयहां इस्तेमाल की जाने वाली कमांड बिल्कुल एक लाइन के इनपुट को स्वीकार करती है और आपके द्वारा टाइप की जाने वाली आखिरी न्यूलाइन उस डेटा का हिस्सा नहीं होगी जिसे पास किया गया है sha1pass।

पात्रों को गूँजने से रोकने के लिए:

sha1pass "$( stty -echo; head -n 1; stty echo )"

stty -echoटर्मिनल पर टाइप पात्रों में से गूंज बंद आदेश बदल जाता है। इसके बाद प्रतिध्वनि बहाल हो जाती है stty echo।

मानक इनपुट पर पारित करने के लिए, उस अंतिम कमांड को बदल दिया जा सकता है ( sha1passमानक इनपुट पर डेटा स्वीकार किए जाने पर आपने ऐसा किया होगा , लेकिन ऐसा प्रतीत होता है जैसे यह विशेष उपयोगिता इसके मानक इनपुट को अनदेखा कर रही है):

{ stty -echo; head -n 1; stty echo; } | somecommand

यदि आपको मल्टी-लाइन इनपुट की आवश्यकता होती है (ऊपर एक एकल लाइन को पारित किया जाना चाहिए, जिसके अंत में कोई नया रेखा वर्ण नहीं है), तो पूरे headकमांड को बदलें catऔर इनपुट को समाप्त कर दें ( somecommandखुद को अंत तक फ़ाइल पढ़ता है) के साथ Ctrl+D( निम्नलिखित Returnयदि आप इनपुट में एक नया वर्ण शामिल करना चाहते हैं, या यदि नहीं तो दो बार)।

यह इस बात पर ध्यान दिए बिना काम करेगा कि आप किस शेल का उपयोग कर रहे हैं (जब तक यह बॉर्न-जैसा या आरसी-जैसा शेल था)।

कुछ शेल अपने इतिहास की फाइलों में टाइप-इन कमांड को सेव न करने के लिए बनाए जा सकते हैं यदि कमांड किसी स्पेस से पहले हो। इसमें आमतौर पर HISTCONTROLमूल्य निर्धारित करना शामिल होता है ignorespace। यह कम से कम bashऔर kshओपनबीएसडी द्वारा समर्थित है , लेकिन उदाहरण के लिए ksh93या dash। zshउपयोगकर्ता अनदेखा करने के लिए एक पैटर्न को परिभाषित करने के लिए histignorespaceविकल्प या उनके HISTORY_IGNOREचर का उपयोग कर सकते हैं।

उन गोले में read, जो टर्मिनल पर गूँजते पात्रों के साथ पढ़ने का समर्थन करते हैं, आप भी उपयोग कर सकते हैं

IFS= read -rs password     # -s turns off echoing in bash or zsh
                           # -r for reading backslashes as-is,
                           # IFS= to preserve leading and trailing blanks
sha1pass "$password"

लेकिन यह स्पष्ट रूप से प्रक्रिया तालिका में पासवर्ड का खुलासा करने के साथ अभी भी एक ही मुद्दा है।

यदि उपयोगिता मानक इनपुट से पढ़ती है, और यदि शेल "यहां-स्ट्रिंग्स" का समर्थन करता है, तो उपरोक्त को बदल दिया जा सकता है

IFS= read -rs password
somecommand <<<"$password"

नीचे टिप्पणियों का सारांश:

कमांड लाइन पर दिए गए पासवर्ड के साथ एक कमांड को निष्पादित करना, जो कि ऊपर दिए गए सभी कमांड करता है, एक को छोड़कर जो कमांड को डेटा को पाइप करता है, संभवतः पासवर्ड psउसी समय चलने वाले किसी व्यक्ति को दिखाई देगा । यदि कोई संवादात्मक शेल से निष्पादित होता है, तो ऊपर दी गई कोई भी कमांड शेल के इतिहास फ़ाइल में टाइप-इन पासवर्ड को नहीं बचाएगा।
अच्छी तरह से व्यवहार किए गए प्रोग्राम जो स्पष्ट-पाठ पासवर्ड पढ़ते हैं, वे अपने मानक इनपुट से, एक फ़ाइल से या सीधे टर्मिनल से पढ़कर ऐसा करते हैं।
sha1pass कमांड लाइन पर पासवर्ड की आवश्यकता होती है, या तो सीधे टाइप किया जाता है या कमांड प्रतिस्थापन के कुछ फार्म का उपयोग किया जाता है।
यदि संभव हो, तो किसी अन्य उपकरण का उपयोग करें।

— कुसलानंद
स्रोत

11

यह गलत है। कमांड विस्तार का परिणाम $(...)कमांड लाइन का हिस्सा होगा और psआउटपुट में दिखाई देगा सिवाय कड़े / खरीद के सिस्टम के।

— आर ..

3

@ कुसलानंद, जब आप ओवरराइट होने लगते हैं, तो एक कमजोर खिड़की छोड़ने के बाद भी आरजीवी को ओवरराइट कर सकते हैं; यह एक शमन है, एक तय नहीं है।

— चार्ल्स डफी

5

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

— चार्ल्स डफी

4

@CharlesDuffy: यहां टूल मूलभूत रूप से टूटा हुआ लगता है। sha1passकमांड लाइन पर बिना पासवर्ड के चलाने से लगता है कि बिना कुछ पढ़े ही आउटपुट आ सकता है ... इसलिए ओपी को एक अलग टूल चुनने की जरूरत है।

— आर ..

8

यह उत्तर सुरक्षा के दृष्टिकोण से असुरक्षित है, और एकमात्र लाभ यह है कि पासवर्ड शेल इतिहास में दिखाई नहीं देता है, लेकिन यह लाभ कमांड के सामने एक स्पेस को शामिल करके पूरा करना आसान है

— फेरीबिग

25

यदि आप HISTCONTROLऐसा सेट करते हैं:

HISTCONTROL=ignorespace

और एक स्थान के साथ कमांड शुरू करें:

~$  mycommand

इसे इतिहास में संग्रहीत नहीं किया जाएगा।

— vfbsilva
स्रोत

10

संवेदनशील डेटा को पाइप या यहाँ से पास करें:

command_with_secret_output | command_with_secret_input

या:

command_with_secret_input <<EOF
$secret
EOF

यह गुप्त (गैर-निर्यात) शेल चर में होने के लिए ठीक है, लेकिन आप कमांड लाइनों पर उन चर का उपयोग कभी नहीं कर सकते हैं, केवल यहां-दस्तावेजों और शेल इंटर्नल में।

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

कमांड विस्तार का उपयोग सुरक्षित नहीं है :

command_with_secret_input "$(command_with_secret_output)"

क्योंकि आउटपुट को कमांड लाइन पर शामिल किया जाएगा और psहार्ड / proc वाले सिस्टम को छोड़कर आउटपुट (या मैन्युअल रूप से / proc से पढ़ना) में दिखाई देगा ।

एक चर के लिए असाइनमेंट ठीक है:

secret=$(command_with_secret_output)

— आर ..
स्रोत

मैं जो देख रहा हूं वह एक वास्तविक कमांड command_with_secret_outputहै जो मुझे गुप्त आउटपुट टाइप करने की अनुमति देता है । क्या ऐसी कोई कमांड मौजूद है जिसे यहाँ प्रतिस्थापित किया जा सकता है?

— cemulate

ध्यान दें कि यहां एक इंटरैक्टिव bash सत्र में दस्तावेज़ टाइप करने से दस्तावेज़ को इतिहास फ़ाइल में सहेजा जाएगा।

— Kusalananda

@cemulate: शेल शेल का उपयोग करें read, जैसे read -r secret। तब आपका रहस्य भीतर है $secret। यदि आप चाहें तो इनपुट छिपाने के लिए आप इसके पहले / बाद में स्टि्ट चला सकते हैं।

— आर ..

3

@ कुसलानंद: sha1passमौलिक रूप से टूटा हुआ / अनुपयोगी / असुरक्षित लगता है क्योंकि यह स्टडिन या फ़ाइल से पासवर्ड नहीं पढ़ सकता है। मुझे लगता है कि समस्या को हल करने के लिए एक अलग उपयोगिता की आवश्यकता है।

— आर ..

1

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

— Kusalananda

6

बस फ़ाइल में मान लिखें और फ़ाइल पास करें:

$ cat > mysecret
Big seecreeeet!
$ cat mysecret | sha1pass

मुझे यकीन नहीं है कि यह कैसे sha1passकाम करता है, अगर यह इनपुट के रूप में फाइल ले सकता है, तो आप उपयोग कर सकते हैं sha1pass < mysecret। यदि नहीं, तो इसका उपयोग करने में catसमस्या हो सकती है क्योंकि इसमें अंतिम न्यूलाइन शामिल है। यदि ऐसा है, तो उपयोग करें (यदि आपका headसमर्थन करता है -c):

head -c-1 mysecret | sha1pass

— terdon
स्रोत

2

अपने पहले उदाहरण में डिस्क पर पासवर्ड क्यों लिखें जब आप बस कर सकते हैं cat | sha1pass? cat mysecret | sha1passऔर sha1pass < mysecretअंतिम newlines के संबंध में एक ही व्यवहार है। catनई कहानियों को नहीं जोड़ता है। वैसे भी, अगर sha1passमानक इनपुट के माध्यम से पासवर्ड पास करने का समर्थन करता है , तो मैं यह उम्मीद करूंगा कि यह स्वयं द्वारा अंतिम नई पंक्ति की उपेक्षा करे। उन पंक्तियों वाली फाइलें जिन्हें नईलाइन द्वारा समाप्त नहीं किया गया है, वे सभी के बाद यूनिक्स में अप्राकृतिक हैं, इसलिए ऐसी फ़ाइल की अपेक्षा करना अजीब होगा, जिसे नईलाइन द्वारा समाप्त नहीं किया गया है।

— जोएल

@JoL i) क्योंकि मैंने ऐसा नहीं सोचा था: / लेकिन यह कैसे काम करेगा? मुझे किसी भी इनपुट को दर्ज करने का मौका देने से पहले cat | sha1passचलाने के लिए लगता है sha1pass। ii) नहीं, निश्चित रूप से cat mysecretएक नई पंक्ति नहीं catजोड़ता है , मैंने कभी नहीं कहा कि इसे जोड़ता है, केवल यह कि इसमें शामिल है।

— terdon

मैं देखता हूं, लेकिन ऐसा नहीं है कि < mysecretइसे हटा दिया जाए। :)

— जोएल

कोई बात नहीं। अब जब मैंने फिर से पढ़ा, तो मैं देख रहा हूं कि आपने कहा था कि बाद में प्रस्ताव करना है head -c-1। मुझे लगता है कि मैं सिर्फ इस उलझन में था कि क्यों उपयोग करें cat mysecret | sha1passऔर फिर बाद में प्रस्ताव करें sha1pass < mysecret। मुझे लगता है कि चिंता यह है कि sha1pass स्टड के लिए नियमित फ़ाइलों के बारे में शिकायत कर सकती है; मुझे यकीन नहीं है कि क्यों।

— जोएल

@JoL यह अधिक है क्योंकि मैंने कभी उपयोग नहीं किया है sha1passऔर -hकुछ मिनटों में मैंने जो खोज की और खर्च किया, उसे खोजने में कोई मैनुअल या या कोई अन्य दस्तावेज नहीं मिल सका, इसलिए यदि इनपुट स्ट्रिंग के रूप में या इनपुट फ़ाइल के रूप में sha1pass fooव्यवहार किया जाए तो यह पता नहीं चल सकता। foo। इसलिए मैंने प्रत्येक संभावना से निपटने के लिए विकल्प दिए।

— terdon

1

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

stty -echo
echo -n "password: "
head -1 | sha1pass
stty echo

जैसे कुसलानंद ने कहा, stty -echoयह सुनिश्चित करता है कि जब तक आप stty echoफिर से नहीं करते तब तक आप जो टाइप करते हैं वह दिखाई नहीं देता । head -1मानक इनपुट से एक पंक्ति प्राप्त करेगा और इसे पास करेगा sha1pass।

— Jol
स्रोत

0

मै इस्तेमाल करूंगा

sha1pass "$(cat)"

catस्टड से तब तक पढ़ा जाएगा EOF, जो Ctrl + D दबाने से हो सकता है। फिर, परिणाम को तर्क के रूप में पारित किया जाएगाsha1pass

— oktupol
स्रोत

3

R .. का उत्तर बताता है कि यह असुरक्षित क्यों है।

— hvd