मूल्यों को हशिंग और सलाम करना

Question

मैं एक छोटा सा वेब ऐप विकसित कर रहा हूं जो आंतरिक रूप से उपयोगकर्ताओं को प्रमाणित करता है। एक बार जब उपयोगकर्ता मेरे वेब ऐप को प्रमाणित कर लेता है तो उपयोगकर्ता जानकारी और व्यक्ति का नाम किसी तृतीय पक्ष वेब एप्लिकेशन पर पास करता है। तीसरा पक्ष डेवलपर यह सुझाव दे रहा है कि हम मूल्य हैश और नमक।

मेरी अज्ञानता को क्षमा करें, लेकिन इसका क्या अर्थ है?

मैं जावा में ऐप लिख रहा हूं। तो मैं जो करने की योजना बना रहा हूं वह उपयोगकर्ता आईडी, व्यक्ति का नाम, और कुछ Math.random() मान को अपाचे कॉमन्स डाइजेस्ट के साथ नमक के रूप में SHA512 का उपयोग करता है और उपयोगकर्ता आईडी और व्यक्ति के नाम के साथ उस शेड स्ट्रिंग को पास करता है।

क्या यह मानक अभ्यास है? मुझे तीसरे पक्ष को नमक को सही से गुजरना चाहिए?

Answer 1

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

hash(password + salt) 

या यहाँ तक कि

hash(hash(password) + salt) 

सुरक्षित रूप से किसी तृतीय पक्ष वेबसाइट में लॉग इन करने के लिए, UserID, नमकीन हैश (ऊपर से) और नमक है कि आप उपयोग भेज सकते हैं (अगर यह नहीं दिया जाता है)। इस वेबसाइट ने अपने पासवर्ड कैसे संग्रहीत किए हैं, इस पर निर्भर करते हुए, आप अपने लिए नमक उत्पन्न कर सकते हैं या आप इससे नमक मांग सकते हैं।

एक विकल्प उपयोगकर्ता आईडी को वेबसाइट पर पहले भेजना है, फिर इसे नमक के साथ प्रतिक्रिया दें, और फिर hash(password+salt)) वेबसाइट पर वापस भेजें।

Answer 2

एक बार जब उपयोगकर्ता अपने वेब एप्लिकेशन प्रमाणीकृत किया जाता है तो एक तिहाई पक्ष वेब आवेदन करने के लिए उपयोगकर्ता ID और व्यक्ति का नाम के रूप में कुछ जानकारी जैसे गुजरता है। तीसरा पक्ष डेवलपर यह सुझाव दे रहा है कि हम मूल्य हैश और नमक।

यह सही नहीं लगता है। हैश एक तरफा ऑपरेशन हैं। आप एक हैश का परिणाम नहीं लेने के लिए और सादे पाठ परमात्मा सकता से यह

क्या मैं कर रहा नमक के रूप में उपयोगकर्ता ID, व्यक्ति का नाम है, और कुछ math.random() मान hashing है पर योजना बना रहा हूँ

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

का उपयोग SHA-256 या SHA-512 ठीक है और क्या NIST recommends

Answer 3

जावा में आप की तरह कुछ कर सकते हैं:

import org.apache.commons.codec.digest.DigestUtils; 
import org.apache.commons.lang.RandomStringUtils; 

/** 
* SHA1-hash the password with the user's salt. 
* 
* @param password 
*/ 
public void setPassword(String password) 
{ 
    if (password.equals(this.password)) 
    { 
     return; 
    } 

    if (passwordSalt == null || passwordSalt.equals("")) 
    { 
     passwordSalt = RandomStringUtils.randomAscii(20); 
    } 

    this.password = DigestUtils.shaHex(password + passwordSalt); 
} 

/** 
* Check if a given password is correct. 
* 
* @param givenPassword 
* @return True is correct, else false. 
*/ 
public boolean checkPassword(String givenPassword) 
{ 
    return (password.equals(DigestUtils.shaHex(givenPassword + passwordSalt))); 
} 

तो पासवर्ड पठनीय नहीं, एक हैकर चुरा भले ही है आपके डीबी।यदि आप एक पर्याप्त बड़ी हैश ले, तो यह प्रभावी रूप से असंभव इंद्रधनुष precompute को हो जाता है:

Answer 4

एक नमक के पूरे मुद्दे का उपयोग कर "इंद्रधनुष तालिकाओं" अव्यवहार्य (देखने के एक संभाव्य बिंदु से कहा जाता है क्या हमलों बनाने के लिए है टेबल)।

http://en.wikipedia.org/wiki/Rainbow_table

सिर्फ एक हैश (एक) कर रहे हैं और हैश भंडारण के बजाय:

:460526e74fd6a25b525e642db2f756a4: 

आप हैश (अ + नमक) करते हैं और आपको हैश और नमक की दुकान (नमक को यादृच्छिक रूप से चुना जा सकता है):

:cdd5bc3f05f6a76f6c82af728b2c555c:346884e6e35be: 

Answer 5

बस एक सिर ऊपर, वहां नमक के साथ क्या करना है इस पर कुछ गलत जानकारी है। नमक को स्टोर करना ठीक और सामान्य है। प्रत्येक पासवर्ड का अपना नमक होना चाहिए जो इसके साथ सादे पाठ में संग्रहीत होता है। इसका मतलब यह है कि किसी ऐसे व्यक्ति के लिए इसे बहुत कठिन बनाना है जिसने पहले से गणना की गई हैश तालिका का उपयोग करके इसे अपने क्रैश पासवर्ड डेटाबेस को पहले से ही चुरा लिया है।

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

Answer 6

मैं देखता हूं कि आपको इस तीसरे पक्ष के ऐप से अधिक जानकारी या कुछ उदाहरण नहीं मिल रहे हैं, जिनके साथ आप काम कर रहे हैं। जो आप वर्णन कर रहे हैं वह सामान्य अभ्यास की तरह प्रतीत नहीं होता है, और ईमानदारी से आपने जो कहा है उसके आधार पर उस भावना को भी समझ में नहीं आता है।

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

यदि वह दूसरा मार्ग है जो वे आपको करने की कोशिश कर रहे हैं, तो यह अनुरोधों से निपटने का कुछ अजीब (और बहुत सुरक्षित नहीं) तरीका है, लेकिन मुझे ठीक लगता है।

तो मैंने कहा जैसे, अगर आप कुछ उदाहरण पा सकते हैं, या यहां तक ​​कि यदि आप यहां प्रश्न में ऐप के बारे में अधिक जानकारी पोस्ट करना चाहते हैं, और हम खुद को देख सकते हैं।