क्या क्रेडिट कार्ड एन्क्रिप्शन के लिए सबसे अच्छा .NET एल्गोरिदम है?

Question

.NET System.Security.Cryptography नेमस्पेस में एल्गोरिदम का एक विचित्र संग्रह है जिसे मैं क्रेडिट कार्ड के विवरणों के एन्क्रिप्शन के लिए उपयोग कर सकता हूं। जो सबसे अच्छा है?

यह स्पष्ट रूप से अपेक्षाकृत छोटी स्ट्रिंग के लिए सुरक्षित होने की आवश्यकता है।

संपादित करें: मैं यूके में हूं, जहां मैं समझता हूं कि हम एन्क्रिप्टेड क्रेडिट कार्ड के विवरणों को ठीक से संग्रहित कर रहे हैं, जब तक कि तीन अंकों वाला सीवीवी नंबर कभी संग्रहित न हो। और महान प्रतिक्रियाओं के लिए सभी को धन्यवाद।

Answer 1

कोई अपराध नहीं, लेकिन सवाल थोड़ा "गुमराह" है। कोई "चांदी बुलेट" समाधान नहीं है। मैं सामान्य रूप से क्रिप्टोग्राफी पर पढ़ने की सिफारिश करता हूं और फिर कुछ खतरे मॉडलिंग करता हूं। कुछ सवाल (कोई एक व्यापक सूची तरह से) आप अपने आप से पूछना चाहिए:

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

बाद में संपादित: ध्यान दें कि एक ही श्रेणी से (उदाहरण के 3DES और एईएस के लिए - दोनों किया जा रहा है सममित ब्लॉक cyphers) मानक एन्क्रिप्शन एल्गोरिदम तुलनीय शक्ति के हैं। अधिकांश (वाणिज्यिक) सिस्टम टूटा नहीं जाता है क्योंकि किसी ने अपने एन्क्रिप्शन को मजबूर कर दिया है, लेकिन क्योंकि उनके खतरे मॉडलिंग को पर्याप्त विस्तृत नहीं किया गया था (या फ्लैट आउट वे नहीं थे)। उदाहरण के लिए आप सभी डेटा एन्क्रिप्ट कर सकते हैं, लेकिन यदि आपके पास सार्वजनिक सामना करने वाला वेब इंटरफ़ेस होता है जो SQL इंजेक्शन के लिए कमजोर है, तो इससे आपको बहुत मदद नहीं मिलेगी।

Answer 2

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

Answer 3

PCI DSS अनुपालन नियमों के अनुसार, किसी भी उद्योग के अग्रणी एन्क्रिप्शन मानक पर्याप्त है। तो 256 बिट कुंजी वाला 3 डीईएस पर्याप्त है (हालांकि अन्य मानकों का उपयोग किया जा सकता है)। इसे देखें http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

Answer 4

इससे कोई फर्क नहीं पड़ता।

पूर्ण कार्ड नंबर डिस्क को कभी छूना नहीं चाहिए।

जो कुछ मायने रखता है वह ऑथ कोड है।

निशान आदि के लिए आप केवल अंतिम 4 अंक xxxx xxxx xxxx 1234 और समाप्ति तिथि का उपयोग करेंगे।

यदि आप कार्ड नंबर स्टोर करना चाहते हैं तो क्रिप्टोग्राफी पसंद अधिग्रहण बैंक द्वारा अनिवार्य किया जाएगा।

जब तक आप अधिग्रहणकर्ता नहीं होते, तब तक एक पुराना यूनिक्स प्रोग्रामर/डीबी 2 लड़का होना चाहिए जो आपको पूछना चाहिए।

< "आप इसे स्थानीय स्तर पर ग्राहक पर एक कुकी में स्टोर नहीं कर सकते" - कभी

Answer 5

वहाँ भी विचार करने के लिए कानूनी पहलू है। मैं कहीं और स्थिति नहीं जानता लेकिन जर्मनी में आपको क्रेडिट कार्ड नंबर ¹⁾ स्टोर करने की अनुमति नहीं है। अवधि। इससे कोई फर्क नहीं पड़ता कि आप उन्हें एन्क्रिप्ट करते हैं या नहीं और आप उन्हें किस प्रारूप में स्टोर करते हैं।

तुम सब मई (और यहाँ मैं स्मृति से चर्चा करते हुए हूँ, किसी भी न्यायिक ज्ञान के बिना) क्रेडिट कार्ड नंबर के एक मजबूत हैश (SHA-256?) की दुकान, अंतिम चार अंक और के साथ है खाता संख्या। और हां, अकेले इन जानकारी से पूरी संख्या का पुनर्निर्माण करना मुश्किल है। कानून हमेशा तार्किक नहीं होते हैं।

---

¹⁾ छोड़कर यदि आप एक संघ प्रमाणित क्रेडिट कार्ड संस्थान कर रहे हैं।

Answer 6

संकेत: आपको जांच करनी चाहिए कि क्या क्रेडिट कार्ड नंबर स्टोर करना कानूनी है या नहीं। उदाहरण के लिए स्वीडन में आपको PCI (Payment Card Industry) द्वारा प्रमाणित किया जाना होगा, जहां आपकी आंतरिक और बाहरी सुरक्षा का परीक्षण किया जाएगा (कई अन्य चीजों के साथ लंबे समय तक)।

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

Answer 7

मैं विचार है कि तुम सिर्फ सादा उन्हें दुकान नहीं करना चाहिए जब तक आप एक बहुत वास्तव में अच्छा कारण है में जोड़ने चाहते हैं, और उन्हें एक कुकी में संग्रहीत एक वास्तव में बुरा विचार है - वे बस के लिए too easy रहे पकड़ लें (क्या होता है अगर कोई कुकी चुरा लेता है - तो इससे कोई फ़र्क नहीं पड़ता कि यह कितना एन्क्रिप्टेड है)।

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

वास्तव में, बस इसे मत करो!

इसके अलावा आपको कभी भी कभी भी सीसीवी कोड नहीं रखना चाहिए।

Answer 8

यहां अखंडता के बारे में मत भूलना। आउट-ऑफ-द-बॉक्स क्रिप्टो के खिलाफ जालसाजी हमले होते हैं जब हमलावर कुंजी को नहीं जानता है, लेकिन सिफरटेक्स्ट में हेरफेर कर सकता है।

• ज्ञात सबस्ट्रिंग

वास्तव में क्रेडिट कार्ड के लिए मामला है कि के साथ संक्षिप्त स्ट्रिंग एन्क्रिप्ट करने,

: ये विशेष रूप से बुरा जब हो सकता है। तो System.Security.Cryptography एईएस या 3 डीईएस सीबीसी मोड में अपने स्वयं के चेकसम को घुमाने के बिना खतरनाक हो सकता है। पढ़ें: कुछ मौका है कि एक गुप्त कुंजी के बिना हमलावर एक क्रेडिट कार्ड नंबर दूसरे के साथ बदल सकता है।

Answer 9

यदि आप किसी तृतीय पक्ष भुगतान गेटवे का उपयोग कर रहे हैं, तो आपको संख्याओं को स्टोर करने की आवश्यकता नहीं है।

कोई बात नहीं है।

Answer 10

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

PHP की openssl_seal की तरह कुछ, हालांकि यदि आप शायद एक अलग एल्गोरिदम के साथ चाहते हैं।