2008-09-19 13 views
17

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

हमारा वर्तमान विचार कार्ड पंजीकृत होने पर क्रेडिट कार्ड की जानकारी के हमारे सिस्टम में हैश (SHA-1) को स्टोर करना है, और हैश की तुलना करने के लिए यह निर्धारित करना है कि कार्ड का उपयोग पहले किया गया है या नहीं।

आमतौर पर, शब्दकोश नमूनों से बचने के लिए नमक का उपयोग किया जाता है। मुझे लगता है कि हम इस मामले में कमजोर हैं, इसलिए हमें शायद हैश के साथ एक नमक स्टोर करना चाहिए।

क्या आप इस विधि में किसी भी दोष को देखते हैं? क्या यह इस समस्या को हल करने का एक मानक तरीका है?

उत्तर

0

हां, इस मामले में हैश की तुलना ठीक से काम करनी चाहिए।

0

एक नमकीन हैश को ठीक काम करना चाहिए। नमक प्रति उपयोगकर्ता प्रणाली होने के कारण बहुत सारी सुरक्षा होनी चाहिए।

+0

मैं सहमत हूं। ध्यान रखें कि यह क्रेडिट कार्ड को ओ (एन) ऑपरेशन पंजीकृत करता है जहां एन पंजीकृत कार्ड की मौजूदा संख्या है। प्लस हैशिंग एक काफी महंगी ऑपरेशन है। – Johan

1

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

this Coding Horror article से

:

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

+0

हां, लेकिन यदि आप प्रत्येक हैश के लिए एक अलग यादृच्छिक नमक का उपयोग करते हैं, तो आपको उस नए मूल्य पर हर नमक को आजमाने की ज़रूरत है, जिसे आप तुलना करना चाहते हैं। एक लंबी यादृच्छिक लेकिन निरंतर स्ट्रिंग + समाप्ति तिथि का प्रयोग करें। –

+0

यदि आप नमक में समाप्ति तिथि का उपयोग कर रहे हैं, तो यह स्थिर कैसे है? – ine

+0

जब तक वे एक शब्दकोश का उपयोग नहीं कर रहे हैं जिसमें समाप्ति तिथि नमक के रूप में शामिल है। –

1

लगभग एक अच्छा विचार।

केवल हैश संग्रह करना एक अच्छा विचार है, इसने दशकों से पासवर्ड की दुनिया में सेवा की है।

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

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

आपको अपने आप से व्यापार का वजन करना होगा। नमक जोड़ने से यह आपके डेटाबेस को सुरक्षित नहीं करता है अगर यह चोरी हो जाता है, तो यह केवल इसे कठिन बना देता है। कितना कठिन है? यदि यह 30 सेकंड की आवश्यकता से हमले को बदलता है तो एक दिन की आवश्यकता होती है, तो आपने कुछ भी हासिल नहीं किया है - यह अभी भी डीकोड किया जाएगा। यदि यह इसे एक दिन से 30 साल में बदल देता है तो आपने विचार करने के लिए कुछ मूल्यवान प्रयास किया है।

+0

आह - और यदि SHA-1 इतना महंगा है कि उस नमक को वास्तव में हैकर वर्षों की लागत होगी तो यह भी महंगा होगा कि आप शायद सीसी संख्या 10,000 में शामिल होने के लिए पीड़ित होंगे। लेकिन आप हमेशा अपने अपेक्षित ग्राहक आधार आकार बनाम इसका परीक्षण कर सकते हैं और देख सकते हैं कि यह दर्द नहीं करता है या नहीं। – Jeff

+2

-1 मुझे खेद है, लेकिन मैं वास्तव में इस उत्तर से असहमत हूं: आप पासवर्ड कार्ड जैसे क्रेडिट कार्ड नंबरों का इलाज नहीं कर सकते हैं, क्योंकि यदि आवश्यक हो तो लोग जटिल पासवर्ड चुन सकते हैं (लंबे, अक्षरों, अंकों और विशेष पात्रों के साथ), जबकि क्रेडिट कार्ड नंबर हैं सिर्फ 16 अंकों के बारे में, और उनमें से आधे को आसानी से अनुमान लगाया जा सकता है (पहला 7 उद्योग मानक है (निक जॉनसन का जवाब देखें), और आखिरी 4 डेटाबेस में संग्रहीत हैं, प्रश्न के अनुसार (और यह सामान्य अभ्यास है)। वास्तव में * नहीं * स्टोर "बस हैश" करें। इसके बजाय, वेज के उत्तर का पालन करें, या मेरा। – MiniQuark

+1

-1 मिनी मुहम्मद सही है। यह योजना यहां किए गए अन्य प्रस्तावों से कम है। तथ्य यह है कि क्रेडिट कार्ड बस अनुमान लगाया जा सकता है यहां। – Accipitridae

0

SHA1 broken है।कोर्स, एक अच्छा प्रतिस्थापन क्या है इस बारे में ज्यादा जानकारी नहीं है। SHA2?

+1

दोनों SHA1 और MD5 केवल इसलिए टूट गए हैं कि एक ही हैश के साथ दो स्ट्रिंग उत्पन्न करना संभव है। हैश के लिए preimages की गणना करने की बात आती है, या जब स्ट्रिंग उत्पन्न करने की बात आती है तो न तो टूटा जाता है एक ज्ञात स्ट्रिंग के रूप में एक ही हैश। –

0

यदि आप कार्ड धारक के नाम (या केवल अंतिम नाम) के साथ कार्ड नंबर के अंतिम 4 अंक जोड़ते हैं और समाप्ति तिथि आपके पास रिकॉर्ड अद्वितीय बनाने के लिए पर्याप्त जानकारी होनी चाहिए। हैशिंग सुरक्षा के लिए अच्छा है, लेकिन क्या आपको डुप्लिकेट चेक के लिए हैश को दोहराने के लिए नमक को स्टोर/याद करने की आवश्यकता नहीं होगी?

+0

हाँ आप करेंगे - बिंदु यह है कि टेबल आधारित हमलों को उत्पन्न करने में काफी समय लगता है। यदि आपके पास प्रत्येक कार्ड नंबर के लिए एक अलग नमक है, तो तालिका का निर्माण केवल आपको, 1 कार्ड पर ही मिलेगा। लागत इसके लायक नहीं है। –

+0

मैं नमकीन हैश के खिलाफ वकालत कर रहा था - मुझे लगता है कि ओपी का उद्देश्य केवल डेटा के कई उदाहरणों को रोकने के लिए है, जो स्वयं के द्वारा मैच के लिए पर्याप्त अद्वितीय नहीं हैं। –

0

मुझे लगता है कि उपर्युक्त संकेत के रूप में एक अच्छा समाधान है, कार्ड नंबर, समाप्ति तिथि और नाम के हैश मूल्य को स्टोर करना होगा। इस तरह आप अभी भी त्वरित तुलना कर सकते हैं ...

2

@Cory आर राजा

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

0

Sha1 टूटा कोई समस्या नहीं है। सभी टूटे हुए साधन यह है कि टकराव की गणना करना संभव है (2 डेटा सेट जिनमें एक ही sha1 है) आप अपेक्षा से अधिक आसानी से कर सकते हैं। यह उनके sha1 के आधार पर मनमानी फ़ाइलों को स्वीकार करने में एक समस्या हो सकती है लेकिन इसमें आंतरिक हैशिंग एप्लिकेशन के लिए कोई रिलीज नहीं है।

3

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

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

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

10

लोग इस बारे में सोचने पर विचार कर रहे हैं, मुझे लगता है। प्रति-रिकॉर्ड अद्वितीय नमक के साथ, नमकीन, अत्यधिक सुरक्षित (उदा। "कम्प्यूटेशनल रूप से महंगा") हैश शा -256 की तरह हैश का उपयोग करें।

आपको पहले कम लागत वाली, उच्च सटीकता जांच करनी चाहिए, फिर उच्च चेक निश्चित जांच केवल तभी करें जब वह चेक हिट हो।

चरण 1: अंतिम 4 अंक के मैचों के लिए

देखो (। और संभवतः भी exp तारीख, हालांकि वहाँ वहाँ कुछ बारीकियों कि को संबोधित आवश्यकता हो सकती है)।

चरण 2:

तो सरल जांच हिट, नमक का उपयोग करें, हैश मान मिलता है, गहराई की जांच में है।

सीसी # के अंतिम 4 अंक सबसे अनूठे हैं (आंशिक रूप से क्योंकि इसमें LUHN चेक अंक भी शामिल है) इसलिए गहराई से जांच का प्रतिशत आप अंततः मिलान नहीं करेंगे (झूठी सकारात्मक दर) बहुत कम, बहुत कम (प्रतिशत का एक अंश) होगा, जो आपको बेवकूफ़ों के सापेक्ष ओवरहेड की जबरदस्त मात्रा बचाता है "हर बार हैश चेक करें" डिज़ाइन।

+0

हैश की तुलना करने से पहले अंतिम 4 अंकों की जांच करने के लिए, यह एक अच्छा विचार की तरह लगता है। धन्यवाद! –

+2

पिछले 4 अंकों को संग्रहीत करने से एक क्रूर बल हमले को और भी सरल बना दिया जाता है। –

+0

@Arachnid दुख की बात है, पिछले 4 अंकों को संग्रहित व्यापारियों के लिए आम अभ्यास है। हालांकि, अगर आप पूरी तरह से अंतिम 4 अंक रखना नहीं चाहते हैं तो आप पहले परीक्षण के रूप में समाप्ति तिथि के साथ तुलना कर सकते हैं। – Wedge

17

चलो थोड़ा गणित करें: क्रेडिट कार्ड संख्या 16 अंकों लंबी है। पहले सात अंक 'प्रमुख उद्योग' और जारीकर्ता संख्या हैं, और अंतिम अंक लुन चेकसम है। यह कुल 100,000,000 खाता संख्याओं के लिए 8 अंक 'मुक्त' छोड़ देता है, संभावित जारीकर्ता संख्याओं की संख्या से गुणा (जो बहुत अधिक होने की संभावना नहीं है)। ऐसे कार्यान्वयन हैं जो प्रतिदिन हार्डवेयर पर प्रति सेकंड लाखों हैंश कर सकते हैं, इससे कोई फर्क नहीं पड़ता कि आप क्या कर रहे हैं, यह बलपूर्वक बल के लिए एक बड़ा सौदा नहीं होगा।

सरासर संयोग से, जब हैश एल्गोरिथ्म मानक देने वाली चीज़ की तलाश, मैं this article about storing credit card hashes पाया है, जो कहते हैं:

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

...

जब क्रेडिट कार्ड नंबर hashing, हैशिंग ध्यान से जानवर सबसे मजबूत उपलब्ध क्रिप्टोग्राफिक हैश कार्यों, बड़े नमक मूल्यों, और कई पुनरावृत्तियों का उपयोग करके मजबूर कर के खिलाफ की रक्षा करने के लिए तैयार किया जाना चाहिए।

पूरा लेख पूरी तरह से पढ़ने योग्य है। दुर्भाग्यवश, अपशॉट ऐसा लगता है कि किसी भी परिस्थिति ने इसे क्रेडिट कार्ड नंबरों को स्टोर करने के लिए 'सुरक्षित' बना दिया है, यह डुप्लिकेट की खोज करने के लिए भी निषिद्ध रूप से महंगा होगा।

5

Do नहीं दुकान एक सरल SHA-1 क्रेडिट कार्ड नंबर के, यह रास्ता आसान करने के लिए दरार (विशेष रूप से के बाद से पिछले 4 अंक में जाना जाता है) होगा। हमारी कंपनी में भी यही समस्या थी: यहां हमने इसे हल किया है।

पहले समाधान

  1. प्रत्येक क्रेडिट कार्ड के लिए, हम अंतिम 4 अंक, समाप्ति तिथि, एक लंबे यादृच्छिक नमक (50 बाइट्स लंबे), और सीसी संख्या के नमकीन हैश की दुकान। हम bcrypt हैश एल्गोरिदम का उपयोग करते हैं क्योंकि यह बहुत सुरक्षित है और जैसा कि आप चाहें सीपीयू-गहन के रूप में देखा जा सकता है। हमने इसे बहुत महंगा (हमारे सर्वर पर लगभग 1 सेकंड प्रति हैश) के रूप में ट्यून किया है। लेकिन मुझे लगता है कि आप इसके बजाय SHA-256 का उपयोग कर सकते हैं और जितनी बार आवश्यक हो उतनी बार पुन: प्रयास कर सकते हैं।
  2. जब कोई नया सीसी नंबर दर्ज किया जाता है, तो हम सभी मौजूदा सीसी संख्याओं को ढूंढकर शुरू करते हैं जो समान 4 अंकों के साथ समाप्त होते हैं और समान समाप्ति तिथि होती है। फिर, प्रत्येक मिलान सीसी के लिए, हम जांचते हैं कि इसके संग्रहित नमकीन हैश नमक वाले हैश से मेल खाता है और उसके नए सीसी नंबर से गणना की जाती है। दूसरे शब्दों में, हम जांचते हैं कि hash(stored_CC1_salt+CC2)==stored_CC1_hash है या नहीं।

चूंकि हमारे पास हमारे डेटाबेस में लगभग 100k क्रेडिट कार्ड हैं, इसलिए हमें लगभग 10 हैंश की गणना करने की आवश्यकता है, इसलिए हमें परिणाम लगभग 10 सेकंड मिलते हैं। हमारे मामले में, यह ठीक है, लेकिन आप थोड़ा सा bcrypt ट्यून करना चाहते हैं। दुर्भाग्यवश, यदि आप करते हैं, तो यह समाधान कम सुरक्षित होगा। दूसरी तरफ, यदि आप बीसीआरपीटी को और भी सीपीयू-गहन होने के लिए ट्यून करते हैं, तो सीसी संख्याओं से मेल खाने में अधिक समय लगेगा।

हालांकि मुझे विश्वास है कि इस समाधान रास्ता बस सीसी संख्या का एक अनसाल्टेड हैश भंडारण की तुलना में बेहतर है, यह एक बहुत प्रेरित समुद्री डाकू एक क्रेडिट तोड़ने के लिए (जो डेटाबेस की एक प्रति प्राप्त करने के लिए प्रबंधन) पर रोक नहीं लगेगी 2 से 5 साल के औसत समय में कार्ड। तो यदि आपके पास अपने डेटाबेस में 100k क्रेडिट कार्ड हैं, और यदि समुद्री डाकू में सीपीयू के है, तो वह हर दिन कुछ क्रेडिट कार्ड नंबर पुनर्प्राप्त कर सकता है!

इससे मुझे विश्वास होता है कि आपको हैश की गणना नहीं करनी चाहिए: आपको इसे किसी और को सौंपना होगा। यह दूसरा समाधान है (हम इस दूसरे समाधान में माइग्रेट करने की प्रक्रिया में हैं)।

दूसरा समाधान

आप अपने भुगतान प्रदाता आपके क्रेडिट कार्ड के लिए उपनाम उत्पन्न की है।

    प्रत्येक क्रेडिट कार्ड के लिए
  1. , तो आप बस जो भी आप (उदाहरण के लिए पिछले 4 अंक & समाप्ति की तारीख) स्टोर करने के लिए प्लस एक क्रेडिट कार्ड नंबर उर्फ ​​चाहते दुकान।
  2. जब कोई नया क्रेडिट कार्ड नंबर दर्ज किया जाता है, तो आप अपने भुगतान प्रदाता से संपर्क करते हैं और इसे सीसी नंबर देते हैं (या आप ग्राहक को भुगतान प्रदाता को रीडायरेक्ट करते हैं, और वह सीसी नंबर सीधे भुगतान प्रदाता की वेबसाइट पर प्रवेश करता है)। बदले में, आपको क्रेडिट कार्ड उपनाम मिलता है! बस। बेशक आपको यह सुनिश्चित करना चाहिए कि आपका भुगतान प्रदाता इस विकल्प को प्रदान करता है, और जेनरेट किया गया उपनाम वास्तव में सुरक्षित है (उदाहरण के लिए, सुनिश्चित करें कि वे क्रेडिट कार्ड नंबर पर केवल SHA-1 की गणना नहीं करते हैं!)। अब समुद्री डाकू संख्या को पुनर्प्राप्त करना चाहते हैं तो समुद्री डाकू को आपके सिस्टम प्रदाता के सिस्टम प्लस को अपने भुगतान प्रदाता की प्रणाली को तोड़ना है।

यह आसान है, यह तेज़ है, यह सुरक्षित है (ठीक है, कम से कम यदि आपका भुगतान प्रदाता है)। मुझे एकमात्र समस्या यह है कि यह आपको अपने भुगतान प्रदाता से जोड़ता है।

उम्मीद है कि इससे मदद मिलती है।

2

मेरा मानना ​​है कि मुझे इस समस्या को हल करने के लिए मूर्ख-प्रमाणित तरीका मिला है। अगर कोई मेरे समाधान में कोई दोष है तो कृपया मुझे सही करें।

  1. ईसी 2, हेरोकू इत्यादि पर एक सुरक्षित सर्वर बनाएं। यह सर्वर एक उद्देश्य और केवल एक उद्देश्य प्रदान करेगा: आपके क्रेडिट कार्ड को हैशिंग।
  2. उस सर्वर पर एक सुरक्षित वेब सर्वर (Node.js, Rails, आदि) स्थापित करें और REST API कॉल सेट करें।
  3. उस सर्वर पर, एक अद्वितीय नमक (1000 वर्ण) और SHA512 इसे 1000 बार उपयोग करें।

इस तरह से, यहां तक ​​कि अगर हैकर्स आपके हैश प्राप्त, वे को तोड़ने के लिए अपने सर्वर में अपने सूत्र खोजने की आवश्यकता होगी।

0

यदि आप स्ट्रिप/ब्रेनट्री जैसे भुगतान प्रोसेसर का उपयोग कर रहे हैं, तो उन्हें "भारी उठाने" दें।

वे दोनों प्रस्ताव कार्ड फिंगरप्रिंटिंग है कि आप सुरक्षित रूप से अपने DB में संग्रहीत करेंगे और अगर एक कार्ड पहले से मौजूद है देखने के लिए बाद की तुलना कर सकते हैं:

  • धारी रिटर्न fingerprint स्ट्रिंग - doc
  • ब्रेनट्री रिटर्न unique_number_identifier string देखते हैं - doc देखना
संबंधित मुद्दे