2010-08-13 12 views
7

मैं अपने कोको एप्लिकेशन का एक परीक्षण हिस्सा बनाने की कोशिश कर रहा हूं। मेरे पास सभी सेट अप (कुंजी सहित) लाइसेंस हैं।मैं उद्देश्य सी के साथ डेटा को सुरक्षित रूप से कैसे स्टोर करूं? (मैक/कोको देव)

लेकिन मैं सोच रहा था कि मैं कैसे स्टोर कर सकता हूं जैसे उपयोगकर्ता ने एक सुरक्षित स्थान पर प्रोग्राम चलाया था, जहां उपयोगकर्ता इसे आसानी से नहीं ढूंढ सकता था और/या इसे संपादित करें।

मुझे NSUserDefaults standardUserDefaults के साथ एक बेवकूफ था, लेकिन उपयोगकर्ता लाइब्रेरी> प्राथमिकताओं में उस डेटा को आसानी से ढूंढ और संपादित कर सकता है।

+0

एप्लिकेशन बंडल के भीतर इसे संग्रहीत करना उपयोगकर्ता के लिए बाधा डालने के लिए * थोड़ा * कठिन हो सकता है। यह निर्भर करता है कि आप कितनी अच्छी सुरक्षा चाहते हैं। – David

+0

यह बहुत अच्छा होना चाहिए क्योंकि मैं नहीं चाहता कि उपयोगकर्ता – Daniel

+0

की समाप्ति के बाद एप्लिकेशन का उपयोग करने में सक्षम हो, मैं सिर्फ NSUserDefaults encodeObject को देख रहा था: के लिए: शायद वे पर्याप्त होंगे? – Daniel

उत्तर

21

मैं इसे सुपर-सुरक्षित बनाने के खिलाफ बहस करता हूं। हमारे पास एक बार सर्वर सक्रियण था लेकिन पूरी तरह से इससे दूर चला गया। यहाँ पर कुछ कारण हैं:

  • यहां तक ​​कि सबसे "सुरक्षित" भंडारण विधि तोड़ा जा सकता है
  • यहां तक ​​कि एक आला उत्पाद के लिए एक दरार विकसित किया जा सकता है, कोई रास्ता नहीं है चारों ओर, चाहे कितना सुरक्षित तरीके
  • कुछ, बहुत महंगे, बहुत सुरक्षित तरीके हैं।अन्य सभी
  • यह निष्पक्ष और ईमानदार उपयोगकर्ताओं के खिलाफ जाता है यह मुश्किल उन्हें समस्याओं के कारण
  • एक उपयोगकर्ता अपने सॉफ्टवेयर दरार करता है या आपकी सुरक्षा में गतिरोध उत्पन्न अगर चीजें ठीक करने के लिए कर रही है फटा दिया है, वह शायद यह भी कभी नहीं करेंगे
  • 80% उपयोगकर्ताओं को भी नहीं जानते कि इसे खरीदा है क्या एक वरीयता फ़ाइल
  • सभी उपयोगकर्ताओं की
  • 95% संभावना के बारे में नहीं लगता है कि आदेश परीक्षण
  • एक आसान तरीका का विस्तार करने में इसे हटाने के लिए है परीक्षण अवधि रीसेट करने के लिए बड़े पैमाने पर आपके उपयोगकर्ताओं के लिए आपका समर्थन आसान बनाता है जो भी कारण
  • पर भरोसा करके उपयोगकर्ताओं के लिए एक दूसरे परीक्षण देने के लिए चींटी एक अच्छा विक्रय बिंदु
  • पावर उपयोगकर्ताओं बहुत अधिक सुरक्षा के साथ सॉफ्टवेयर के खिलाफ बारी के लिए करते हैं है

मैं बहुत यकीन है कि वहाँ कुछ कर रहे हैं कि हूँ, लेकिन इन विचारों से बहुत कम, अपवाद। मैं कहूंगा: पंजीकरण सुरक्षा पर अपना समय बर्बाद न करें, लेकिन

+1

मैं सहमत हूं, अपने ऐप को सुपर सुरक्षित बनाने के लिए बहुत से संसाधनों को बर्बाद न करें। हैकर इसे बाईपास करने का एक तरीका ढूंढेंगे। –

+1

http://www.aquaticmac.com/ सुरक्षा के समाधान में एक अच्छी बूंद है। http://aquaticmac.com/cocoa.php भी एन्क्रिप्शन करने के लिए एनएसडीटा पर अच्छा विस्तार है। यदि आप% 99 उपयोगकर्ताओं को कवर करना चाहते हैं, तो मैं एक स्पष्ट नाम यानी "। " के साथ छिपी हुई फ़ाइल दृष्टिकोण की अनुशंसा करूंगा। – Intentss

2

किसी फ़ाइल को संग्रहीत करने का प्रयास करें जिसका नाम कुछ फ़ोल्डर में एक अवधि के साथ शुरू होता है और फिर फ़ाइल के छिपे हुए ध्वज को सेट करता है।

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

#include <assert.h> 
#include <stdio.h> 
#include <stddef.h> 
#include <string.h> 
#include <sys/attr.h> 
#include <sys/errno.h> 
#include <unistd.h> 
#include <sys/vnode.h> 

typedef struct attrlist attrlist_t; 

struct FInfoAttrBuf { 
    u_int32_t length; 
    fsobj_type_t objType; 

    union { 
     char rawBytes[32]; 

     struct { 
      FileInfo info; 
      ExtendedFileInfo extInfo; 
     } file; 

     struct { 
      FolderInfo info; 
      ExtendedFolderInfo extInfo; 
     } folder; 
    } finderInfo; 
}; 
typedef struct FInfoAttrBuf FInfoAttrBuf; 


- (int)SetFileInvisibility:(NSString *)filePath state:(BOOL)isInvisible) { 
    attrlist_t attrList; 
    FInfoAttrBuf attrBuf; 

    char *path = [filePath cStringUsingEncoding: NSUTF8StringEncoding]; 

    memset(&attrList, 0, sizeof(attrList)); 
    attrList.bitmapcount = ATTR_BIT_MAP_COUNT; 
    attrList.commonattr = ATTR_CMN_OBJTYPE | ATTR_CMN_FNDRINFO; 

    int err = getattrlist(path, &attrList, &attrBuf, sizeof(attrBuf), 0); 
    if (err != 0) 
     return errno; 

    // attrBuf.objType = (VREG | VDIR), inconsequential for invisibility 

    UInt16 flags = CFSwapInt16BigToHost(attrBuf.finderInfo.file.info.finderFlags); 

    if (isInvisible) 
     flags |= kIsInvisible; 
    else 
     flags &= (~kIsInvisible); 

    attrBuf.finderInfo.file.info.finderFlags = CFSwapInt16HostToBig(flags); 

    attrList.commonattr = ATTR_CMN_FNDRINFO; 
    err = setattrlist(path, &attrList, attrBuf.finderInfo.rawBytes, sizeof(attrBuf.finderInfo.rawBytes), 0); 

    return err; 
} 

मैं इस सवाल का जवाब से इस कोड को संशोधित तुम वहाँ अधिक उपयोगी जानकारी प्राप्त हो सकता है::

यहाँ कुछ कोड है कि फाइल को छिपाने के लिए काम करना चाहिए है How to make a file invisible in Finder using objective-c

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

यदि आपके पास व्यवस्थापकीय विशेषाधिकार हैं तो आप फ़ाइल पर एक सूडो chmod निष्पादित कर सकते हैं और इसे केवल पढ़ने के लिए सेट कर सकते हैं, लेकिन आपको अपना ऐप उपयोगकर्ता को उनके पासवर्ड के लिए नहीं पूछना चाहिए।

3

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

Common Crypto डाइजेस्ट लाइब्रेरी में देखें।

यह लगभग सभी आकस्मिक उपयोगकर्ताओं से रक्षा करेगा। हालांकि हैकर्स पर्याप्त प्रेरणा के साथ, घुसपैठ करने का एक तरीका समझ सकते हैं।

4

आप फाइल सिस्टम पर एक फ़ाइल का उपयोग नहीं कर सकते हैं। कोई भी जो इसे बेकार/क्रैक करना चाहता है वह बुनियादी, मानक ओएसएक्स सुविधाओं के माध्यम से फ़ाइल एक्सेस को ट्रैक करने के तरीके के बारे में जानने के लिए पर्याप्त स्मार्ट होगा। तो एक फाइल जोड़ा जा रहा है। इतना ही नहीं, लेकिन उन फ़ाइलों को बनाने का बुरा व्यवहार है जिन्हें आप अनइंस्टॉल करते समय हटा नहीं पाते हैं। लोगों को अपने परीक्षण ऐप को हटाने के बाद संसाधनों का उपभोग नहीं करना चाहिए।

जैसा ऊपर बताया गया है, आपके बंडल में गड़बड़ करना भी एक बुरा विचार है। यह आपको तीन मौलिक विकल्पों के साथ छोड़ देता है।

1) इसके बारे में चिंता न करें। एक मानक समाप्ति प्रणाली का उपयोग करें जो मानक स्थानों और विधियों का उपयोग करता है। आप अभी भी आपके द्वारा संग्रहीत डेटा में एन्क्रिप्शन का उपयोग कर सकते हैं, लेकिन जानते हैं कि वह भी टूटा जाएगा। स्वीकार करें कि कॉपीराइट उल्लंघन तब तक नहीं होगा जब तक कि आपका ऐप पूरी तरह से अलोकप्रिय न हो।

2) नेटवर्क कॉल का उपयोग करें और सर्वर पर सत्यापन करें। इसके लिए ऐप को हमेशा चलाने के लिए आपकी सेवा तक पहुंचने में सक्षम होना आवश्यक होगा। यह सामान्य रूप से एक अच्छा विचार नहीं है। क्या होगा यदि आपके सर्वर नीचे हैं? क्या होगा अगर वे ऑफलाइन हैं? क्या होगा यदि आपके और उनके बीच एक नेटवर्क समस्या होती है? उन सभी परिदृश्य होने जा रहे हैं। जब वे करते हैं तो आप संभावित रूप से ग्राहकों को खो देंगे जब तक कि आपके ऐप को पहले से ही संचालित करने के लिए आपके सर्वर से कनेक्शन की आवश्यकता न हो (जैसे ट्विटर या फेसबुक कहें)।

3) आवेदन बंडल के साथ मिलकर या अनाथ फाइलों को छोड़कर "खराब नागरिक" बनें। यदि आप इसे बाद में करते हैं, कम से कम सुनिश्चित करें कि वे स्पष्ट रूप से नामित हैं ताकि वे आपके आवेदन से स्पष्ट रूप से संबंधित हों।

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

आप ऐप को बेहतर बनाने के लिए अपने संसाधनों को खर्च कर सकते हैं, या लोगों को परीक्षण अवधि के दौरान इसका उपयोग न करने वाले लोगों के बारे में बेहतर महसूस कर सकते हैं। उनमें से एक आपकी बिक्री बढ़ा सकता है, और कोई नहीं करेगा।

[संपादित करें] मुझे यह भी इंगित करना चाहिए कि इन चीजों को क्रैक करने का सबसे आम (यदि सबसे आम नहीं है) बाइनरी को संशोधित करना है। तो बंडल मकिंग के माध्यम से कोड हस्ताक्षर तोड़कर आप वास्तव में उस विधि को स्वयं खोलेंगे क्योंकि आप अपने पास बेहतर सुरक्षा में से एक तोड़ चुके होंगे। अधिकांश दरारों में बाइनरी को संशोधित किया जाता है जैसे चेक जो नियमित रूप से सफल प्रमाणीकरण देता है।

3

एलन ओडगार्ड को कोको सॉफ्टवेयर के लिए लाइसेंस कुंजी बनाने/स्टोर करने के लिए OpenSSL का उपयोग करने के तरीके पर एक सुंदर सभ्य writeup है। एक पढ़ा लायक हो सकता है।

0

यह समाधान मेरे लिए बहुत अच्छा काम करता है। इसे आजमाएं: https://github.com/nielsmouthaan/SecureNSUserDefaults। यह आपके उपयोगकर्ताडिफॉल्ट फ़ाइल में एन्क्रिप्टेड बूल/स्ट्रिंग/फ्लोट/पूर्णांक स्टोर करेगा। उम्मीद है कि यह वही है जो आप चाहते हैं। सुनिश्चित करें कि आप कोकोसा सुरक्षा डाउनलोड करें और जोड़ें (डाउनलोड लिंक के लिए SecureNSUserDefaults GitHub पृष्ठ देखें)। CocoaSecurity SecureNSUSerDefaults का एक आवश्यक तत्व है, इसलिए आपको इसे अपनी किसी भी फाइल में आयात करने की आवश्यकता नहीं है। आपको Base64 भी डाउनलोड करना होगा, जो CocoaSecurity का एक आवश्यक तत्व है। आपको अपनी परियोजना में बेस 64 जोड़ने की भी आवश्यकता है, लेकिन इसे अपनी किसी भी फाइल में आयात करने की आवश्यकता नहीं है।

उपयोग

आयात हेडर फाइल कहीं भी आप एन्क्रिप्शन विधि का उपयोग करना चाहते हैं।

[[NSUserDefaults standardUserDefaults] setSecret:@"your_secret_goes_here"]; 

मैं संख्याओं और अक्षरों का एक यादृच्छिक स्ट्रिंग पैदा करने की सलाह देते हैं:

#import <SecureNSUserDefaults/NSUserDefaults+SecureAdditions.h> 

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

NSString *retrievedData = [[NSUserDefaults standardUserDefaults]  
    secretStringForKey:@"the_key_your_object_will be_stored_under"]; 

मुझे आशा है कि इस मदद करता है:

[[NSUserDefaults standardUserDefaults] 
    setSecretObject:@"your_secret_object" 
    forKey:@"the_key_your_object_will be_stored_under"]; 

स्ट्रिंग को पुनः प्राप्त करने के लिए, इस विधि का उपयोग!

संबंधित मुद्दे