Les meilleures pratiques pour ranger et protéger les clés API dans les applications

1. Comme il est, votre application compilée contient la clé des chaînes, mais aussi les noms de constantes APP_KEY et APP_SECRET. L'extraction de clés à partir d'une telle auto-documenter le code est trivial, par exemple avec la norme Android outil dx.

2. Vous pouvez appliquer ProGuard. Il laissera la clé des chaînes intacte, mais il va supprimer les noms de constantes. Il permettra également de renommer les classes et les méthodes à court, sans noms, dans la mesure du possible. L'extraction de touches, puis prend un peu plus de temps, pour décider de la chaîne qui sert de but.

   Note que la mise en place ProGuard ne devrait pas être aussi difficile que vous avez peur. Pour commencer, il vous suffit d'activer ProGuard, comme indiqué dans le projet.les propriétés. Si il y a des problèmes avec les bibliothèques de tiers, vous devrez peut-être supprimer certaines mises en garde et/ou de les empêcher d'être occulté, dans proguard-project.txt. Par exemple:

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

   C'est une force brute approche; vous pouvez affiner une telle configuration, une fois le traité de demande de travaux.

3. Vous pouvez dissimuler les chaînes manuellement dans votre code, par exemple avec un encodage Base64 ou, de préférence, avec quelque chose de plus compliqué, peut-être même code natif. Un hacker va alors statiquement la rétro-ingénierie de l'encodage ou de façon dynamique intercepter le décodage dans le bon endroit.

4. Vous pouvez appliquer un commercial obfuscator, comme ProGuard est spécialisée frère DexGuard. Il peut en outre chiffrer/masquer les cordes et les classes pour vous. L'extraction de touches, puis prend encore plus de temps et d'expertise.

5. Vous pourriez être en mesure d'exécuter les parties de votre application sur votre propre serveur. Si vous pouvez garder les clés de là, ils sont en sécurité.

En fin de compte, c'est économique, ce que vous avez à faire: quelle est l'importance des touches, comment beaucoup de temps ou de logiciel ne peut vous le permettre, le degré de sophistication sont les pirates qui sont intéressés dans les keys, de combien de temps ils veulent passer, que vaut un délai avant que les touches sont piratés, sur ce que l'échelle, la réussite de tout les pirates distribuer les clés, etc. De petits morceaux d'informations comme les touches sont plus difficiles à protéger que de l'ensemble des applications. Intrinsèquement, rien sur le côté client est incassable, mais vous pouvez certainement élever la barre.

(Je suis le développeur de ProGuard et DexGuard)

OriginalL'auteur Eric Lafortune

De suivre 3 étapes simples pour sécuriser API/clé Secrète

Nous pouvons utiliser Gradle pour fixer la clé de l'API ou de la clé Secrète.

1. gradle.properties (propriétés du Projet) : Créer une variable avec la clé.

GoolgeAPIKey = "Your API/Secret Key"

2. construire.gradle (Module: app) : Définir la variable dans la construction.gradle pour accéder à l'activité ou du fragment. Ajouter le code ci-dessous pour buildTypes {}.

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

3. L'accès en Activité/Fragment par application BuildConfig :

BuildConfig.GoogleSecAPIKEY

Mise à jour :

La solution ci-dessus est utile dans le projet open source d'engager plus de Git. (Merci à David Rawson et riyaz-ali pour votre commentaire).

Que par l'Matthieu et Pablo Cegarra commentaires de la façon décrite ci-dessus n'est pas sécurisé et Decompiler permettra à quelqu'un pour afficher l'BuildConfig avec nos clés secrètes.

Solution :

Nous pouvons utiliser NDK pour Sécuriser les Clés API. Nous pouvons stocker les clés dans le natif C/C++ de la classe et de l'accès dans nos classes Java.

Veuillez suivre cette blog pour sécuriser les clés API à l'aide de NDK.

Un suivi sur la façon de stocker les jetons de sécurité dans Android

OriginalL'auteur SANAT

Une solution possible est d'encoder les données dans votre application et de l'utilisation de décodage au moment de l'exécution (lorsque vous souhaitez utiliser des données). Je vous recommande également d'utiliser progaurd à faire du mal à lire et comprendre le décompiler le code source de votre application . par exemple, j'ai mis une clé codée dans l'application et ensuite utilisé un décoder méthode dans mon appli pour décoder mes clés secrètes à l'exécution:

//"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=="));
}

Décompilé le code source d'un proguarded app est: est-ce

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

Au moins, c'est assez compliqué pour moi. c'est la façon dont je le fais quand j'ai pas le choix, mais de stocker une valeur dans mon application. Bien sûr, nous savons tous que C'est pas la meilleure façon mais cela fonctionne pour moi.

/**
 * @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";
}

Décompilé version:

 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";
      }
    }
  }

et vous pouvez trouver de nombreuses encryptor classes avec un peu de recherche dans google.

OriginalL'auteur Milad Faridnia

Cet exemple a un certain nombre de différents aspects. Je vais mentionner quelques points que je ne pense pas avoir été explicitement couverts par ailleurs.

Protéger le secret en transit

La première chose à noter est que l'accès à l'API dropbox à l'aide de leur l'authentification d'application mécanisme requiert que vous transmettiez votre clé et le secret. La connexion HTTPS, ce qui signifie que vous ne pouvez pas intercepter le trafic sans connaître le certificat TLS. C'est pour empêcher une personne de l'interception et la lecture des paquets sur leur voyage à partir de l'appareil mobile vers le serveur. Pour les utilisateurs normaux, c'est vraiment une bonne façon d'assurer la confidentialité de leur trafic.

Ce qu'il n'est pas bon, c'est de prévenir une personne malveillante du téléchargement de l'application et inspecte le trafic. Il est vraiment facile à utiliser un man-in-the-middle proxy pour l'ensemble du trafic dans et hors d'un appareil mobile. Il ne nécessiterait pas de démontage ou de reverse engineering de code pour extraire l'application de la clé et le secret dans ce cas, en raison de la nature de l'API Dropbox.

Vous pourriez faire l'épinglage qui vérifie que le certificat TLS vous recevoir à partir du serveur est celui que vous attendez. Cela ajoute une case pour le client et le rend plus difficile à intercepter le trafic. Ce serait plus difficile pour inspecter le trafic en vol, mais l'épinglage de vérifier qui se passe dans le client, de sorte qu'il serait probablement toujours être possible de désactiver l'épinglage de test. Il est plus difficile cependant.

Protéger le secret au repos

Comme une première étape, en utilisant quelque chose comme proguard aidera le rendre moins évident où les secrets sont organisées. Vous pouvez également utiliser le NDK pour stocker les clés et les secrets et les envoyer directement des demandes, ce qui permettrait de réduire considérablement le nombre de personnes ayant les compétences appropriées pour extraire l'information. Plus de dissimulation peut être obtenue en ne stockant pas les valeurs directement dans la mémoire, pour toute longueur de temps, vous pouvez crypter et décrypter juste avant de l'utiliser comme suggéré par une autre réponse.

Options plus avancées

Si vous vous êtes paranoïaque à propos de mettre le secret de n'importe où dans votre application, et vous avez du temps et de l'argent à investir dans des solutions plus complètes, alors vous pourriez envisager de stocker les informations d'identification sur vos serveurs (si vous en avez). Cela permettrait d'augmenter le temps de latence de tous les appels à l'API, ce qui aura pour communiquer par l'intermédiaire de votre serveur, et pourrait augmenter les coûts de fonctionnement de votre service en raison de l'augmentation du débit de données.

Ensuite, vous devez décider de la meilleure façon de communiquer avec votre serveurs pour s'assurer qu'ils sont protégés. Ceci est important pour prévenir tous les mêmes problèmes à venir de nouveau avec votre API interne. La meilleure règle que je puisse donner est de ne pas transmettre tout secret directement à cause de l'homme-dans-le-milieu de la menace. Au lieu de cela, vous pouvez signer le trafic à l'aide de votre secret et de vérifier l'intégrité de toutes les demandes qui viennent à votre serveur. Un standard de la façon de le faire est de calculer un HMAC du message à la clé sur un secret. Je travaille dans une entreprise qui a un produit de sécurité qui fonctionne également dans ce domaine et c'est pourquoi ce genre de choses m'intéresse. En fait, ici, est un blog article de l'un de mes collègues qui passe au-dessus de la plupart de cette.

Combien devrais-je faire?

Avec tous les conseils de sécurité comme cela, vous devez faire un rapport coût/avantage de décision au sujet de la façon dont vous voulez le faire pour quelqu'un à l'effraction. Si vous êtes une banque de protéger des millions de clients, votre budget est totalement différent de quelqu'un soutien à une application dans leur temps libre. Il est pratiquement impossible d'empêcher quelqu'un de la rupture de votre système de sécurité, mais dans la pratique peu de gens ont besoin de toutes les cloches et de sifflets et avec certaines précautions de base, vous pouvez obtenir un long chemin.

OriginalL'auteur ThePragmatist

L'ajout de @Manohar Reddy solution, firebase Base de données ou de firebase RemoteConfig (avec Null valeur par défaut) peut être utilisé:

1. De chiffrement de vos clés
2. Stocker dans firebase base de données
3. L'obtenir pendant l'Application de démarrage ou chaque fois que nécessaire
4. déchiffrer les clés et les utiliser

Ce qui est différent dans cette solution?

• pas credintials pour firebase
• firebase l'accès est protégé de sorte seule application avec un certificat signé ont
  le privilège de faire des appels de l'API
• de chiffrement/déchiffrement pour empêcher un homme au milieu d'une interception. Cependant
  les appels déjà https pour firebase

OriginalL'auteur Ayman Al-Absi

Ce que vous faites pour sécuriser vos clés secrètes ne va pas être une réelle solution. Si un développeur peut décompiler l'application il n'y a aucun moyen de garantir la clé, de cacher la clé est juste la sécurité par l'obscurité et est donc obfuscation du code. Problème avec l'obtention d'une clé secrète est que, pour sûr, vous devez utiliser une autre clé et cette clé doit également être assurée. Pensez à une clé cachée dans une boîte qui est verrouillé avec une clé. Vous placez une boîte à l'intérieur d'une chambre et de verrouillage de la chambre. Vous êtes de gauche avec une autre clé de la sécurité. Et que la clé est toujours en cours d'être codé en dur à l'intérieur de votre application.

De sorte que si l'utilisateur entre un code PIN ou un membre de phrase il n'y a aucun moyen de cacher la clé. Mais pour cela, vous devez disposer d'un système pour la gestion de PINs qui se passe hors de la bande, ce qui signifie par le biais d'un autre canal. Certainement pas pratique pour la sécurisation des clés pour des services comme Google Api.

OriginalL'auteur user1611728

Le seul vrai moyen de garder ces privé est de les garder sur votre serveur, et l'application d'envoyer quoi que ce soit pour le serveur, et le serveur interagit avec Dropbox. De cette façon, vous ne JAMAIS distribuer votre clé privée dans n'importe quel format.

OriginalL'auteur Nick