2012-06-28 15 views
18

मैं प्वाइंट-ऑफ-सेल प्रोजेक्ट पर काम कर रहा हूं जो हमारी कंपनी को एक विशेष बैंक द्वारा दिया जाता है। बैंक ने एक डीएलएल प्रदान किया है जो यूएसबी पोर्ट के माध्यम से पीओएस के साथ बातचीत करता है। मैंने कहा है कि डीएलएल जो .NET C# भाषा में लिखा गया है, इसलिए कोई इंटरऑपरेबिलिटी समस्याएं मौजूद नहीं हैं। डीएलएल के अंदर एक विधि है जिसे DebitAndShareTheAmount कहा जाता है। इस विधि में दो मुख्य पैरामीटर P1,P2 हैं।मुझे सी # में अपनी विधि पहुंच सुरक्षा को कैसे हल करना चाहिए?

P1 प्लेन में राशि है और P2 बैंक ऋण पर साथ 1000-1010 = 990 $ और मेरे खाते राशि जो plaintext.So में फिर से P1 से घटा दिया जाना चाहिए अगर मैं फोन DebitAndShare(1000,10); है // यह वास्तव में होगा मेरे ऐप 10 $ का उपयोग करके खरीदारी करें।

समस्या यह है कि सी # प्रोग्रामिंग के कुछ बुनियादी ज्ञान और उस दुकान के कंप्यूटर तक पहुंच के साथ कोई भी विजुअल स्टूडियो स्थापित कर सकता है और उस डीएलएल का उपयोग कर सकता है और डेबिट एंडशेयर विधि को कॉल कर सकता है और आप बाकी को जानते हैं। असल में हमारा ऐप सेवा के रूप में कार्य करने जा रहा है प्रदाता और देश भर में विशेष दुकानों में उपलब्ध, दुकान के मालिकों को हमारे ऐप में ग्राहकों को सेवा प्रदान करके भुगतान किया जाएगा और उनकी राशि (10 $) ले जाएगी। मैं सुरक्षा समस्या के बारे में पीओएस डेवलपर्स के साथ बैठक करने जा रहा हूं मैंने अभी उल्लेख किया है।

मैं एमसीटीएस पुस्तक और पुस्तक के सुरक्षा अनुभाग में गया हूं, मुझे पता चला है कि यदि बैंक डीएलएल PublisherIdentityPermission(SecurityAction.InheritanceDemand, [email protected]"SomeCert.cer") डेबिट एंडशेयर विधि से पहले विशेषता का उपयोग करता है और इस विधि को संरक्षित के रूप में चिह्नित करता है तो हमारे पास एक स्तर की सुरक्षा हो सकती है, क्या यह सही है ? आपके सुझाव क्या हैं। मुझे यह भी लगता है कि अगर बैंक हमें एन्क्रिप्शन एल्गोरिदम दृष्टिकोण दे सकता है, तो यह भी पर्याप्त होगा।

+16

यदि किसी ने आपकी मशीन पर भौतिक पहुंच को अनजान किया है, तो गेम पहले ही खो गया है। इसे रोकने पर ध्यान दें। – dlev

+2

डीएलएल के साथ छेड़छाड़ क्यों करें जब मैं सीधे यूएसबी के माध्यम से अपने लैपटॉप पर पीओएस संलग्न कर सकता हूं और इसके साथ सभी प्रकार की चीजें कर सकता हूं? –

+2

आप दोनों सही हैं। समाधान क्या है? – mosini

उत्तर

0

जैसा कि टिप्पणियां इंगित करती हैं, आपको इसे सुरक्षित करने में गंभीर समस्या होगी। हालांकि, कुछ दृष्टिकोण दिमाग में आते हैं जो कम से कम मदद करेंगे।

  1. स्टैक चलें। अपनी कॉलसाइट में, वर्तमान स्टैक को देखें, और बैक अप लें। यदि आप कुछ भी देखते हैं जो आप उम्मीद नहीं करते हैं, तो असफल हो जाते हैं। यह मूर्खतापूर्ण नहीं है, लेकिन यह उन लोगों को रोक देगा जो कुशल नहीं हैं और/या आपका स्रोत कोड देख सकते हैं।

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

  3. सी ++ में अपना कोड पुनर्निर्माण करें। मशीन कोड को खोजने में मुश्किल होती है, लेकिन यह अभी भी किसी ऐसे व्यक्ति को नहीं रोकेगा जो विंडोज इंटीरियर जानता है।

इसके बजाय अपने अनुप्रयोग प्राप्त करके सागर खाली करने के लिए कोशिश कर के

, आप अनेक उपाय ले जा सकते हैं, और उसके बाद क्या बैंकों करते हैं। उन पैटर्न की तलाश करें जो समझ में नहीं आते हैं। यदि कोई विशेष पीओएस आमतौर पर 100 के आदेश पर मूल्य उत्पन्न करता है, जब आप एक बड़ा या छोटा ऑर्डर देखते हैं, तो समीक्षा के लिए इसे ध्वजांकित करें। लेनदेन में अचानक वृद्धि? वही चीज।

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

एरिक

+0

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

-2

हम देरी पर हस्ताक्षर का उपयोग कर किया जाना चाहिए। बैंक का अधिकृत व्यक्ति डिवाइस में सही हस्ताक्षरित डीएलएल तैनात करता है। बैंक इसे अपनी निजी कुंजी के साथ संकेत देता है।

इसके माध्यम से सभी कॉल प्रामाणिक होंगे और अन्य सभी हैकिंग अनुरोध हैं।

+3

यह कैसे मदद करेगा? ओपी की स्थिति में कोड हस्ताक्षर बिल्कुल उपयोगी नहीं है। – CodesInChaos

0

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

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

यदि यह काम नहीं करता है, तो मेरे पास कोई और समझदार विचार नहीं है (जब तक स्रोत को रीसायकल बिन में न रखें या परमाणु बंकर गणना में स्रोत को लॉक न करें)।

1

जो आप करने की कोशिश कर रहे हैं वह आपके ऐप को क्रैक होने से रोकता है, यह licensing issue i faced previously के समान है, मुझे समुदाय से कोई अच्छा समाधान नहीं मिला है, लेकिन केवल कुछ अच्छे सुझाव हैं, यहां कोई फर्क नहीं पड़ता कि कैसे कोई फर्क नहीं पड़ता जब तक आप किसी मशीन पर कोड को निष्पादित नहीं कर रहे हैं, तब तक जब तक आपके उपयोगकर्ता तक पहुंच हो, तब तक यह हमेशा अतिसंवेदनशील होता है, अकेले कोड obfuscation छोड़ दें, यहां तक ​​कि एन्क्रिप्शन आपके ऐप को पर्याप्त कौशल वाले निर्धारित क्रैकर से कुछ बार सुरक्षित नहीं रख सकता है, और आपके आवेदन के साथ गड़बड़ करने की लाभप्रदता का निर्धारण करते हुए, कई निर्धारित एक होंगे (केवल एक चीज है कि उन्हें यह जानना आवश्यक है कि यह किया जा सकता है, और वे कौशल के साथ कुछ पाएंगे)।

मैं यहां निराशावादी की तरह लग सकता हूं, लेकिन यह सच सच है।

मेरे अनुसार सबसे अच्छा तरीका कोड के उन हिस्सों को स्थानांतरित करना होगा जो केंद्रीय सर्वर पर क्रैक होने की अधिक संभावना है, और उन तरीकों का पर्दाफाश करें जैसे वेब-सर्विसेज पर कॉल करता है। मुझे पता है कि यह पूरी तरह से सुरक्षित नहीं है, recent Apple app store hack याद रखें। सुनिश्चित करें कि आपने सभी बेहतरीन प्रथाओं और आशाओं का पालन किया है, आपको किसी अन्य व्यक्ति से

+1

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