अनुप्रयोगों में निजी API कुंजियों को संग्रहीत और संरक्षित करने के लिए सर्वोत्तम अभ्यास [बंद]

Question

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

यह मानते हुए कि मेरे पास कुछ ऐसा है, मैं गुप्त कुंजी की रक्षा कैसे कर सकता हूं:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

निजी कुंजी संग्रहीत करने के लिए आपकी राय में सबसे अच्छा और सबसे सुरक्षित तरीका क्या है? आपत्ति, एन्क्रिप्शन, आपको क्या लगता है?

Comments

rammic.github.io/2015/07/28/hiding-secrets-in-android-apps

— पैट्रिक डॉर्न

मेरे पास इमेज / png में स्टोर था और बफ़र के रूप में png के माध्यम से कुंजी प्राप्त कर रहा था

— Sumit

मुझे लगता है कि यह एक वैध चिंता का विषय है और इसी तरह के मुद्दे को Firebase Android SDK github पृष्ठ: github.com/firebase/firebase-android-sdk/issues/1583 पर पोस्ट किया है । देखते हैं कि क्या यह संभाला जाता है।

— ग्रीबलॉन

Answer 1

1. जैसा कि यह है, आपके संकलित एप्लिकेशन में प्रमुख तार हैं, लेकिन निरंतर नाम APP_KEY और APP_SECRET भी हैं। इस तरह के स्व-दस्तावेजीकरण कोड से कुंजियाँ निकालना, उदाहरण के लिए, मानक Android उपकरण dx के साथ है।

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

   ध्यान दें कि ProGuard की स्थापना आपको डर के रूप में मुश्किल नहीं होनी चाहिए। के साथ शुरू करने के लिए, आपको केवल ProGuard को सक्षम करने की आवश्यकता है, जैसा कि project.properties में प्रलेखित है। यदि तृतीय-पक्ष पुस्तकालयों के साथ कोई समस्या है, तो आपको कुछ चेतावनियों को दबाने की आवश्यकता हो सकती है और / या उन्हें प्रॉपर-प्रोजेक्ट.टेक्स्ट में बाधित होने से रोक सकते हैं। उदाहरण के लिए:

   -dontwarn com.dropbox.**
   -keep class com.dropbox.** { *; }
   

   यह एक जानवर-बल दृष्टिकोण है; संसाधित एप्लिकेशन के काम करने के बाद आप ऐसे कॉन्फ़िगरेशन को परिष्कृत कर सकते हैं।

3. आप अपने कोड में मैन्युअल रूप से स्ट्रिंग को बाधित कर सकते हैं, उदाहरण के लिए बेस 64 एनकोडिंग या अधिमानतः कुछ अधिक जटिल के साथ; शायद देशी कोड भी। एक हैकर को तब आपके एन्कोडिंग को स्टैटिकली रिवर्स-इंजीनियर करना होगा या डायनामिक रूप से डिकोडिंग को उचित स्थान पर रोकना होगा।

4. आप ProGuard के विशेष सिबलिंग DexGuard की तरह एक कमर्शियल ऑबफसकेटर लगा सकते हैं । यह आपके लिए स्ट्रिंग्स और क्लासेस को अतिरिक्त रूप से एन्क्रिप्ट / बाधित कर सकता है। चाबी निकालने के बाद और भी अधिक समय और विशेषज्ञता प्राप्त होती है।

5. आप अपने खुद के सर्वर पर अपने आवेदन के कुछ हिस्सों को चलाने में सक्षम हो सकते हैं। यदि आप वहां चाबियां रख सकते हैं, तो वे सुरक्षित हैं।

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

(मैं ProGuard और DexGuard का डेवलपर हूं)

Comments

@EricLafortune से कोई फर्क नहीं पड़ता अगर जावा कुंजी बनाम स्ट्रिंग संसाधन XML में निजी कुंजी स्ट्रिंग संग्रहीत है?

— एलन

@EricLafortune क्या अब कुंजी को सुरक्षित रूप से संग्रहीत करने के लिए Android Keystore सिस्टम का उपयोग करना संभव है? ( developer.android.com/training/articles/keystore.html )

— डेविड थॉमस

@DavidThomas: क्या आपने कीस्टोर का उपयोग करने की कोशिश की थी। मैं जावा क्लास में लिखी एक एपीआई कुंजी को बाधित करना चाहता हूं। कृपया जवाब दें

— सागर त्रेहन

क्या Android KeyStore इसके लिए उपयोगी है? ( developer.android.com/training/articles/… )

— वीशी ज़ेंग

मैं # 5 नहीं समझता। क्या यह मूल समस्या के समान सटीक समस्याएं नहीं हैं?

— पीट

Answer 2

कुछ विचार, मेरी राय में केवल पहले कुछ गारंटी देता है:

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

2. अपने रहस्यों को जेनी कोड में रखें, अपने पुस्तकालयों को अपघटन के लिए बड़ा और अधिक कठिन बनाने के लिए कुछ चर कोड जोड़ें। आप कुछ भागों में कुंजी स्ट्रिंग को विभाजित कर सकते हैं और उन्हें विभिन्न स्थानों पर रख सकते हैं।

3. ऑबफ्यूज़ेटर का उपयोग करें, कोड हैशेड सीक्रेट में भी डालें और बाद में जब उपयोग करने की आवश्यकता हो तो उसे अनहैश करें।

4. अपनी गुप्त कुंजी को संपत्ति में अपनी छवि के अंतिम पिक्सेल के रूप में रखें। फिर जरूरत पड़ने पर इसे अपने कोड में पढ़ें। अपने कोड को Obfuscating को उस कोड को छिपाने में मदद करनी चाहिए जो इसे पढ़ेगा।

यदि आप यह देखना चाहते हैं कि आपको एपीके कोड पढ़ना कितना आसान है, तो APKAnalyser को पकड़ो:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

Comments

यदि उपयोगकर्ता एप्लिकेशन को डिकंपाइल कर सकता है, तो वे संभवतः उस अनुरोध को निर्धारित कर सकते हैं जो आपके स्वयं के सर्वर से किया गया था और बस गुप्त प्राप्त करने के लिए निष्पादित करें। यहाँ कोई चांदी की गोली नहीं है, लेकिन कुछ कदम उठाएँ और मुझे यकीन है कि आप ठीक हो जाएंगे! यदि आपका ऐप सुपर लोकप्रिय है, तो शायद नहीं .. महान विचार!

— मैट वोल्फ

हाँ, नंबर 1 कोई गारंटी नहीं देता है।

— २

मुझे वास्तव में छवियों के अंदर चाबियाँ छिपाने का विचार पसंद है। +1

— इगोर --ordaš

@ MarcinJ likedrzejewski आप आगे के समाधान के बारे में और अधिक (नमूना या स्निप्ड कोड के साथ) अधिक समझाना चाहेंगे? धन्यवाद।

— डॉ.अजकी

@ Mr.Hyde को यह स्टेग्नोग्राफ़ी कहा जाता है, इसका एक नमूना कोड यहाँ देने के लिए बहुत जटिल है, आप Google पर उदाहरण पा सकते हैं। मुझे यहां एक मिला है: dreamincode.net/forums/topic/27950-steganography । यह विचार बहुत अच्छा है लेकिन चूंकि एपीके कोड का विघटन किया जा सकता है इसलिए यह इसकी सुंदरता को बिगाड़ता है।

— मार्सिनज

Answer 3

एक अन्य दृष्टिकोण यह है कि डिवाइस में पहले स्थान पर रहस्य न हो! देखें मोबाइल API सुरक्षा तकनीक (विशेष रूप से भाग 3)।

अप्रत्यक्ष समय की सम्मानित परंपरा का उपयोग करते हुए, अपने एपीआई एंडपॉइंट और ऐप प्रमाणीकरण सेवा के बीच रहस्य साझा करें।

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

प्रत्येक एपीआई कॉल के साथ टोकन भेजा जाता है जहां अनुरोध पर कार्य करने से पहले समापन बिंदु अपने हस्ताक्षर को सत्यापित कर सकता है।

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

इसलिए यदि आप अपने रहस्य को सुरक्षित रखना चाहते हैं, तो इसे अपने ऐप में पहले स्थान पर न रखना एक बहुत अच्छा तरीका है।

Comments

यह स्वीकृत उत्तर होना चाहिए।

— ortonomy

जब आप प्रमाणीकरण सेवा तक पहुँचना चाहते हैं तो समस्या बनी रहती है। यह आपको क्लाइंट आईडी और क्लाइंट सीक्रेट देगा। हमें उन्हें कहाँ बचाना चाहिए?

— आशि

निजी एपिस को हल नहीं करता है जहाँ आपको इसका उपयोग करने के लिए पहले अपने एपीआई को प्रमाणित करना होगा। आप सभी ऐप उपयोगकर्ताओं के लिए क्रेडेंशियल कहां से प्राप्त करते हैं?

— किबोटू

Answer 4

पुराना असुरक्षित तरीका:

API / गुप्त कुंजी ( पुराना उत्तर ) सुरक्षित करने के लिए 3 सरल चरणों का पालन करें

एपीआई कुंजी या गुप्त कुंजी को सुरक्षित करने के लिए हम ग्रेडल का उपयोग कर सकते हैं।

1. gradle.properties (परियोजना गुण): कुंजी के साथ चर बनाएं।

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (मॉड्यूल: ऐप): इसे गतिविधि या टुकड़े में एक्सेस करने के लिए build.gradle में चर सेट करें। नीचे दिए गए कोड को buildTypes {} में जोड़ें।

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. एप्लिकेशन के बिल्डकॉन्फिग द्वारा इसे गतिविधि / प्रसार में एक्सेस करें:

BuildConfig.GoogleSecAPIKEY

अपडेट करें :

उपरोक्त समाधान Git पर प्रतिबद्ध करने के लिए ओपन सोर्स प्रोजेक्ट में सहायक है। (आपकी टिप्पणी के लिए डेविड रॉसन और रियाज़-अली का धन्यवाद)।

मैथ्यू और पाब्लो सीगर्रा की टिप्पणियों के अनुसार उपरोक्त तरीका सुरक्षित नहीं है और डेकोम्पिलर किसी को हमारे गुप्त कुंजी के साथ बिल्डकॉन्फिग देखने की अनुमति देगा।

समाधान :

हम API कुंजी को सुरक्षित करने के लिए NDK का उपयोग कर सकते हैं। हम मूल C / C ++ वर्ग में कुंजियाँ संग्रहीत कर सकते हैं और उन्हें हमारे जावा कक्षाओं में एक्सेस कर सकते हैं।

NDK का उपयोग करके एपीआई कुंजियों को सुरक्षित करने के लिए कृपया इस ब्लॉग का अनुसरण करें ।

एंड्रॉइड में सुरक्षित रूप से टोकन स्टोर करने के तरीके के बारे में अनुवर्ती

Comments

फ़ाइल में एक कुंजी संग्रहीत करना सुरक्षित है?

— Google

@Google gradle.propertiesको Git में चेक नहीं करना चाहिए, इसलिए यह गुप्त स्रोत कोड से बाहर गुप्त रखने का एक तरीका है, कम से कम

— डेविड रॉसन

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

— रियाज़-अली

Java Decompiler के उपयोग से किसी को BuildConfig फ़ाइल और "GoogleSecAPIKEY" देखने की अनुमति मिलेगी

— मैथ्यू

आपकी BuildConfig.javaफ़ाइल में सादे पाठ के रूप में कुंजी होगी। यह ओपी पहले से जो कर रहा है, उससे बेहतर नहीं है।

— आइकमैन

Answer 5

ऐप-सीक्रेट कुंजी को निजी रखा जाना चाहिए - लेकिन ऐप जारी करते समय उन्हें कुछ लोगों द्वारा उलट दिया जा सकता है।

उन लोगों के लिए जो इसे छिपाएंगे नहीं, या तो ProGuardकोड को लॉक करें । यह एक परावर्तक है और कुछ भुगतान किए गए ओफ़्फ़सुकेटर्स jk433g34hg3 स्ट्रिंग को वापस पाने के लिए कुछ बिटवाइज़ ऑपरेटरों को सम्मिलित कर रहे हैं । यदि आप 3 दिन काम करते हैं तो आप 5 -15 मिनट तक हैकिंग कर सकते हैं :)

सबसे अच्छा तरीका है कि इसे वैसे ही रखा जाए, जैसा कि इहो।

यहां तक ​​कि अगर आप सर्वर साइड (अपने पीसी) पर स्टोर करते हैं, तो कुंजी को हैक किया जा सकता है और प्रिंट आउट किया जा सकता है। शायद यह सबसे लंबा लगता है? किसी भी तरह यह कुछ मिनटों या कुछ घंटों में सबसे अच्छा मामला है।

एक सामान्य उपयोगकर्ता आपके कोड को अपघटित नहीं करेगा।

Comments

अच्छी तरह से - जवाब मुझे नहीं मिला =) ... मैंने सोचा था कि आप महान सुरक्षा प्राप्त कर सकते हैं :(

— बेसिक कोडर

क्षमा करें, यह वैसा नहीं है जैसा आप एक शानदार, अति सुरक्षित समाधान चाहते थे, बल्कि उन लोगों के लिए जो कंपाइलर का उपयोग कर सकते हैं, डिकंपाइलर कोई सुरक्षित जावा कोड नहीं है: यहां तक ​​कि मूल कोड को हेक्सा दर्शक और डिक्रिप्टेड के साथ देखा जा सकता है। कम से कम एक कोशिश के लायक ...

हालांकि वास्तविक कुंजी की रक्षा नहीं करना चाहिए ..? सबसे अच्छी बात यह है कि कुछ सरल एनस्क्रिप्ट / डिक्रिप्ट रूटीन हैं, जो कि मोटे तौर पर छिप जाएंगे।

— २१

यह डिक्रिप्शन रूटीन "दिखाई" देता है, रिवर्स करना आसान है और आपके पास मूल स्ट्रिंग है

Answer 6

एक संभव उपाय यह है कि आप अपने ऐप में डेटा को एनकोड करें और रनटाइम पर डिकोडिंग का उपयोग करें (जब आप उस डेटा का उपयोग करना चाहते हैं)। मैं आपके ऐप के विघटित स्रोत कोड को पढ़ने और समझने के लिए इसे कठिन बनाने के लिए प्रोगौरड का उपयोग करने की भी सलाह देता हूं। उदाहरण के लिए मैंने ऐप में एक इनकोड की हुई चाबी लगाई और फिर रनटाइम में अपनी गुप्त कुंजियों को डिकोड करने के लिए अपने ऐप में एक डिकोड विधि का उपयोग किया:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

एक प्रॉटेक्टेड ऐप का डिकम्पोज्ड सोर्स कोड यह है:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

कम से कम यह मेरे लिए काफी जटिल है। यह वह तरीका है जब मेरे पास कोई विकल्प नहीं होता है लेकिन मैं अपने आवेदन में एक मूल्य रखता हूं। बेशक हम सभी जानते हैं कि यह सबसे अच्छा तरीका नहीं है लेकिन यह मेरे लिए काम करता है।

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

विघटित संस्करण:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

और आप गूगल में थोड़ी खोज के साथ इतने सारे एनक्रिप्टर्स क्लासेस पा सकते हैं।

Answer 7

@ मनोहर रेड्डी समाधान, फायरबेस डेटाबेस या फायरबेस रिमोटकॉनफिग (नल डिफ़ॉल्ट मान के साथ) का उपयोग किया जा सकता है:

1. अपनी चाबियों का सिपहसालार
2. इसे फायरबेस डेटाबेस में स्टोर करें
3. जब भी आवश्यकता हो ऐप स्टार्टअप के दौरान या इसे प्राप्त करें
4. कुंजी को समझने और इसका उपयोग करें

इस समाधान में क्या अलग है?

• फायरबेस के लिए कोई क्रेडिट नहीं
• फायरबेस एक्सेस सुरक्षित है इसलिए केवल हस्ताक्षरित प्रमाण पत्र के साथ ऐप को एपीआई कॉल करने का विशेषाधिकार है
• मध्यम पुरुष अवरोधन को रोकने के लिए ciphering / deciphering। हालाँकि पहले से ही https को firebase पर कॉल करता है

Comments

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

— आशि

एक फायदा हालांकि, सुझाए गए समाधान के साथ, हम हैकर के सामने एक और जटिलता जोड़ रहे हैं।

— आशी

Answer 8

इस उदाहरण के कई पहलू हैं। मैं उन दो बिंदुओं का उल्लेख करूंगा जो मुझे नहीं लगता कि स्पष्ट रूप से कहीं और कवर किए गए हैं।

पारगमन में रहस्य की रक्षा

ध्यान देने वाली पहली बात यह है कि उनके ऐप प्रमाणीकरण तंत्र का उपयोग करते हुए ड्रॉपबॉक्स एपीआई तक पहुंचने के लिए आपको अपनी कुंजी और गुप्त संचारित करने की आवश्यकता होती है। कनेक्शन HTTPS है जिसका अर्थ है कि आप TLS प्रमाणपत्र को जाने बिना ट्रैफ़िक को रोक नहीं सकते। यह एक व्यक्ति को मोबाइल डिवाइस से सर्वर तक उनकी यात्रा पर पैकेट को इंटरसेप्ट करने और पढ़ने से रोकने के लिए है। सामान्य उपयोगकर्ताओं के लिए यह उनके यातायात की गोपनीयता सुनिश्चित करने का एक अच्छा तरीका है।

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

आप पिनिंग कर सकते हैं जो यह जांचता है कि सर्वर से आपको प्राप्त होने वाला टीएलएस प्रमाणपत्र वह है जिसकी आप अपेक्षा करते हैं। यह क्लाइंट के लिए एक चेक जोड़ता है और ट्रैफ़िक को रोकना अधिक कठिन बनाता है। इससे फ्लाइट में ट्रैफिक का निरीक्षण करना कठिन हो जाता है, लेकिन क्लाइंट में पिनिंग चेक होता है, इसलिए संभवत: पिनिंग टेस्ट को निष्क्रिय करना संभव होगा। यह हालांकि यह कठिन बना देता है।

आराम करने पर राज की रक्षा करना

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

अधिक उन्नत विकल्प

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

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

मुझे कितना करना चाहिए?

इस तरह की किसी भी सुरक्षा सलाह के साथ आपको लागत / लाभ का निर्णय लेने की आवश्यकता है कि आप इसे किसी को तोड़ने के लिए कितना कठिन बनाना चाहते हैं। यदि आप एक बैंक हैं जो लाखों ग्राहकों की रक्षा कर रहा है तो आपका बजट किसी ऐप का समर्थन करने वाले व्यक्ति से बिल्कुल अलग है। खाली समय। किसी को अपनी सुरक्षा को तोड़ने से रोकना लगभग असंभव है, लेकिन व्यवहार में कुछ लोगों को सभी घंटियाँ और सीटी की आवश्यकता होती है और कुछ बुनियादी सावधानियों के साथ आप एक लंबा रास्ता तय कर सकते हैं।

Comments

आप बस इसे यहाँ से कॉपी और पेस्ट करें: स्रोत को स्वीकार किए बिना hackernoon.com/mobile-api-security-techniques-682a5da4fe10 ।

— ortonomy

@ortonomy मैं सहमत हूं कि उसे आपके द्वारा लिंक किए गए लेख को उद्धृत करना चाहिए था, लेकिन वह इसे भूल गया होगा क्योंकि दोनों एक ही जगह पर काम करते हैं ...

— Exadra37

इसके अलावा स्किप के लेख और जिस ब्लॉग पोस्ट पर वे आधारित हैं, वह मेरे जवाब के एक हफ्ते बाद सामने आया।

— thePragmatist

Answer 9

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

Comments

समस्या यह है - उस सर्वर तक पहुंचने के लिए, जिसमें सभी secrects हैं, मुझे एक और सीक्रेट कुंजी का उपयोग करना चाहिए - मुझे आश्चर्य है कि मैं इसे कहां रखूंगा? ;) मैं क्या कहना चाह रहा हूं - यह भी सबसे अच्छा समाधान नहीं है (लगता है कि यहां एक आदर्श समाधान नहीं है)

— बुध

यह सच नहीं है, आपका सर्वर पूरी तरह से आपके नियंत्रण में है। इसके लिए जो आवश्यक है वह पूरी तरह आपके ऊपर है।

— बर्नार्ड इगिरि

क्या आप यहां बता सकते हैं कि क्लाइंट उस डेटा को एन्क्रिप्ट कर सकता है जिसे वह सर्वर पर भेजना चाहता है, जबकि चाबियाँ सर्वर साइड में हैं? और अगर आपका जवाब होगा - सर्वर क्लाइंट को चाबियाँ भेजता है - तो इसे भी सुरक्षित किया जाना चाहिए! फिर से कोई जादू समाधान! आप देख नहीं सकते ?!

— बुध

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

— केन

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

— बर्नार्ड इगिरि

Answer 10

firebase databaseऐप शुरू होने पर इसे गुप्त रखें और इससे प्राप्त करें, यह वेब सेवा को कॉल करने से कहीं बेहतर है।

Comments

लेकिन फायरबेस को क्रेडेंशियल्स के बारे में क्या?

— the_joric

दुर्भाग्य से, फायरबेस डेटाबेस चीन में काम नहीं करता है।

— कोनजेंगबम

समझ में नहीं आता है, हमलावर आपको डिकोड किए गए कोड से फायरबेस विवरण देख सकते हैं और अपने डेटाबसे से कोई भी डेटा प्राप्त कर सकते हैं

— user924

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

— अयमान अल-अबी

जब आप नेटवर्क के माध्यम से फायरबेस डेटाबेस से रहस्य प्राप्त करते हैं, तो एक सुरक्षित (https) चैनल के माध्यम से किसी अन्य वेब सेवा से एक ही रहस्य प्राप्त करने से अधिक सुरक्षित कैसे है? क्या तुम समझा सकते हो?

— सेसाबा तोथ

Answer 11

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

इसलिए जब तक उपयोगकर्ता पिन या वाक्यांश दर्ज नहीं करता है, तब तक कुंजी को छिपाने का कोई तरीका नहीं है। लेकिन ऐसा करने के लिए आपके पास बैंड से बाहर हो रहे पिन के प्रबंधन के लिए एक योजना होनी चाहिए, जिसका अर्थ है एक अलग चैनल के माध्यम से। Google API जैसी सेवाओं के लिए कुंजी हासिल करने के लिए निश्चित रूप से व्यावहारिक नहीं है।

Answer 12

युग पुरानी पोस्ट, लेकिन अभी भी काफी अच्छी है। मुझे लगता है कि एनडीके और सी ++ का उपयोग करते हुए इसे .so पुस्तकालय में छिपाना बहुत अच्छा होगा। .so फाइलें एक हेक्स संपादक में देखी जा सकती हैं, लेकिन अच्छी किस्मत विघटित होती है कि: पी

Comments

उपयोगकर्ता साझा लाइब्रेरी में आसानी से फ़ंक्शन कॉल कर सकते हैं और वहां जो कुछ भी छिपा रहे हैं उसे प्राप्त कर सकते हैं। इसे डिकॉपाइल करने की आवश्यकता नहीं है।

— david72

Androidauthority.com/ के अनुसार फिलहाल Android में इसे करने का कोई सुरक्षित तरीका नहीं है।

— david72

@ अहमद को समझ में नहीं आता कि यह 3 अपवोट क्यों है। कोई भी आसानी से ऐप को

— डिकम्पोज

यह उत्तर लगभग सर्वश्रेष्ठ विकल्पों में से एक है, लेकिन लेखक को यह उल्लेख करना चाहिए कि यह बहुत महत्वपूर्ण है कि आपको कॉल करना चाहिए (अपने NDK लाइब्रेरी के अंदर) यह देखने के लिए कि क्या चेकसम आपके एपीके से मेल खाता है, अन्यथा कोई आपके NDK लाइब्रेरी के बाहर कॉल कर सकता है आपका एप्लिकेशन

— स्टॉयचो एंड्रीव

@ स्नाइपर जो महान होगा, इसके अलावा एक बड़ी समस्या है। आप कैसे जानते हैं कि मूल विधि "कॉलिंग" क्या है? अगर आप हार्ड-कोड को एपीके का नाम जाँचने के लिए, महान, लेकिन क्या होगा अगर मैं अपने "हैक" को एपीके "अच्छा" apk के समान फ़ोल्डर बनाऊं? यह जाँच करेगा कि "अच्छा" एपीके में अच्छा चेकसम है, और यह मुझे उस मूल विधि को निष्पादित करने की अनुमति देगा। जब तक जेएनआई / सी ++ पक्ष से कॉलर फ़ाइल को जानने का कोई तरीका नहीं है, तब तक यह अन्य विकल्पों के रूप में व्यर्थ है।

— सॉकेटबाइट

Answer 13

इन निजी को रखने का एकमात्र सही तरीका यह है कि आप उन्हें अपने सर्वर पर रखें, और ऐप को सर्वर पर जो कुछ भी है, उसे भेजें और सर्वर ड्रॉपबॉक्स के साथ इंटरैक्ट करता है। इस तरह आप किसी भी प्रारूप में अपनी निजी कुंजी वितरित नहीं करते हैं।

Comments

लेकिन आप बाकी दुनिया को सर्वर पर कॉल करने से कैसे रोकते हैं?

— user2966445

यदि "सर्वर" द्वारा आप अपने वेबसर्वर का मतलब जहां क्रेडेंशियल्स हैं - आप किसी भी विधि का उपयोग कर सकते हैं जिसे आप चाहते हैं। उपयोगकर्ता नाम / पासवर्ड, ओहूत, सक्रिय निर्देशिका, आदि के साथ सरल प्रमाणीकरण आदि वास्तव में आपके आवेदन पर निर्भर करता है।

— निक

हो सकता है कि मुझे कुछ याद आ रहा हो, लेकिन क्या इसके बाद भी ऐप के भीतर साख जमा करने की आवश्यकता नहीं है?

— user2966445 21

सही है, लेकिन आपने कहा कि ऐप पहले सर्वर से प्रमाणित होगा। क्या इसका मतलब ऐप में क्रेडेंशियल्स का एक और सेट स्टोर करना नहीं है? मैं समझता हूं कि सर्वर वास्तविक ड्रॉपबॉक्स कॉल को संभालेगा।

— user2966445

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

— निक

Answer 14

कड़वे अनुभव के आधार पर, और एक आईडीए-प्रो विशेषज्ञ के साथ परामर्श करने के बाद सबसे अच्छा समाधान कोड के एक प्रमुख भाग को DLL / SharedObject में ले जाना है, फिर इसे सर्वर से लाएं और रनटाइम पर लोड करें।

संवेदनशील डेटा को एन्कोड किया जाना चाहिए क्योंकि ऐसा कुछ करना बहुत आसान है:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD

Comments

और आप कहा सर्वर के लिए क्रेडेंशियल्स कहाँ जमा कर रहे हैं?

— ZX9