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

Question

मैं ऐसी कई परियोजनाएं करता हूं जिनमें स्वचालित रूप से फॉर्म सबमिट करना और/या वेबसाइटों से डेटा पुनर्प्राप्त करना शामिल है। इनमें से कुछ साइटों को उपयोगकर्ता नाम/पासवर्ड प्रमाणीकरण की आवश्यकता है। (इन साइटों एपीआई नहीं है, तो मैं स्क्रीन scraping पर भरोसा कर रहा हूँ।)

ट्यूटोरियल मैं किसी अन्य पोस्ट डेटा की तरह यूज़रनेम और पासवर्ड स्रोत कोड में स्टोर देखा है, उदाहरण के लिए में से अधिकांश:

string username = "someUserName"; 
string password = "somePassword"; 
// submit POST data... 

लेकिन मुझे पता है कि सादा पाठ में पासवर्ड संग्रहीत करना आमतौर पर फहराया जाता है। क्या मुझे एक वैकल्पिक विधि का उपयोग करना चाहिए?

Answer 1

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

एक विकल्प एक रिवर्सिबल हैश का उपयोग करना होगा, जैसे बेस 64 को पासवर्ड एन्कोड करना, लेकिन यह सादा पाठ में इसे संग्रहीत करने से वास्तव में बहुत सुरक्षित नहीं है।

जहां तक ​​मैं देख सकता हूं, सबसे अच्छा समाधान डेटाबेस में पासवर्ड स्टोर करना होगा। यदि आप उपयोगकर्ता नाम और पासवर्ड प्राप्त करने के बारे में वास्तव में चिंतित हैं, तो आप उन्हें encryption functions के साथ डीबी में एन्क्रिप्ट कर सकते हैं, या आप SQLite डेटाबेस का उपयोग कर सकते हैं जिसे आप डिस्क पर सीधे एन्क्रिप्ट करेंगे।

इस प्रकार आपका कोड और लॉगिन प्रमाण-पत्र अलग-अलग हैं, और आप सुरक्षित रूप से सुरक्षा के बारे में चिंता किए बिना दूसरों के साथ अपना कोड सुरक्षित रूप से साझा कर सकते हैं।

Answer 2

एन्क्रिप्ट और डिक्रिप्ट करने का एक बहुत ही आसान तरीका extended tiny encription algorithm (XTEA) है। मैं यहां विकिपीडिया से सी ++ कोड चिपका रहा हूं, लेकिन ध्यान रखें कि कोई भी इसे वहां बदल सकता था। सही यह प्राप्त करने के बाद प्रवेश पृष्ठों के लिए
1. HTTPS (यदि आवश्यक हो)
2. पासवर्ड एन्क्रिप्शन:

#include <stdint.h> 

/* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */ 

void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { 
    unsigned int i; 
    uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9; 
    for (i=0; i < num_rounds; i++) { 
     v0 += (((v1 << 4)^(v1 >> 5)) + v1)^(sum + key[sum & 3]); 
     sum += delta; 
     v1 += (((v0 << 4)^(v0 >> 5)) + v0)^(sum + key[(sum>>11) & 3]); 
    } 
    v[0]=v0; v[1]=v1; 
} 

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { 
    unsigned int i; 
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds; 
    for (i=0; i < num_rounds; i++) { 
     v1 -= (((v0 << 4)^(v0 >> 5)) + v0)^(sum + key[(sum>>11) & 3]); 
     sum -= delta; 
     v0 -= (((v1 << 4)^(v1 >> 5)) + v1)^(sum + key[sum & 3]); 
    } 
    v[0]=v0; v[1]=v1; 
} 

Answer 3

आप दो काम करने की है।

private static String passwordEncryption(String oldPass){ 
    String newPass = ""; 
    try { 
     MessageDigest messageDigest = MessageDigest.getInstance("MD5"); 
     messageDigest.update(oldPass.getBytes(), 0, oldPass.length()); 
     newPass = new BigInteger(1,messageDigest.digest()).toString(16); 
     if (newPass.length() < 32) { 
      newPass = "0" + newPass; 
     } 
     return newPass; 
    } catch (NoSuchAlgorithmException e) { 
     e.printStackTrace(); 
    } 
    return newPass; 

} 

और का उपयोग MD5() MySQL के समारोह संग्रहीत एक साथ प्राप्त पासवर्ड तुलना करने के लिए: एक एनकोडर कुछ इस तरह है।

Answer 4

एक पैटर्न हम उपयोग करते हैं:

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

यह डबल एन्क्रिप्टिंग क्यों?

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

कमजोरी स्पष्ट रूप से सिस्टम-व्यापी पासवर्ड है। इसे कहीं स्मृति में होना चाहिए।

मैं कोई क्रिप्टोग्राफर नहीं हूं, और मुझे पूरा यकीन है कि उपर्युक्त उप-इष्टतम है। हालांकि, यह काम करता है, सादे पाठ में तृतीय पक्ष सेवा प्रमाण-पत्रों को संग्रहीत करने के बजाय प्रबंधनीय और बहुत सुरक्षित है।

Answer 5

ऐसा करने का कोई तरीका नहीं है। इसे स्क्रिप्ट टेक्स्ट (या "रिवर्सिबल एन्क्रिप्शन") के रूप में कहीं भी स्क्रिप्ट के लिए उपलब्ध होना होगा।

कई एपिस (उदाहरण के लिए अमेज़ॅन वेब सर्विसेज समेत) पर्यावरण परिवर्तनीय में क्रेडेंशियल्स सेट करने की सिफारिश करेंगे और यह संभवतः उतनी ही सुरक्षा है जितनी आप उम्मीद कर सकते हैं।

इसे अपने .bash_profile में रखें, दोबारा जांच की जांच करें, और कम से कम आप यह सुनिश्चित कर सकते हैं कि यह सार्वजनिक रिपो में गिथब पर समाप्त नहीं होगा।

Answer 6

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

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

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

एक त्वरित खोज के बाद मुझे openssl और एन्क्रिप्टिंग स्ट्रिंग का उपयोग करने के बारे में this आलेख मिला।

मुझे एहसास है कि यह एक बहुत पुरानी पोस्ट है, लेकिन उम्मीद है कि यह अगले व्यक्ति की मदद करता है जो इस समस्या पर ठोकर खाती है।