在应用程序中存储和保护私有API密钥的最佳实践

大多数应用程序开发人员会将一些第三方库集成到他们的应用程序中。如果要访问服务（例如Dropbox或YouTube）或记录崩溃。第三方库和服务的数量惊人。大多数这些库和服务通过某种方式与服务进行身份验证来集成，大多数情况下，这是通过API密钥进行的。为了安全起见，服务通常会生成一个公共和私有密钥，通常也称为秘密密钥。不幸的是，为了连接到服务，必须使用此私钥进行身份验证，因此可能是应用程序的一部分。不用说，这面临着巨大的安全问题。可以在几分钟内从APK中提取公共和私有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

}

您认为存储私钥的最佳和最安全的方法是什么？混淆，加密，您怎么看？

1. 实际上，已编译的应用程序包含键字符串，还包含常量名称APP_KEY和APP_SECRET。例如，使用标准的Android工具dx，从这样的自记录代码中提取密钥很简单。

2. 您可以应用ProGuard。它将使键字符串保持不变，但是将删除常量名称。只要有可能，它还将使用简短，无意义的名称重命名类和方法。然后，提取密钥需要花费更多时间，以弄清楚哪个字符串可以达到什么目的。

   请注意，设置ProGuard并不像您担心的那样困难。首先，仅需要启用ProGuard，如project.properties中所述。如果第三方库有任何问题，则可能需要在proguard-project.txt中禁止某些警告和/或防止混淆它们。例如：

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

   这是蛮力的方法；您可以在处理后的应用程序正常运行后改进此类配置。

3. 您可以在代码中手动混淆字符串，例如使用Base64编码，或者最好使用更复杂的东西。甚至本地代码。然后，黑客将不得不对您的编码进行静态反向工程，或者在适当的位置动态拦截解码。

4. 您可以应用商业混淆器，例如ProGuard的专业兄弟姐妹DexGuard。它还可以为您加密/混淆字符串和类。这样，提取密钥将花费更多的时间和专业知识。

5. 您也许可以在自己的服务器上运行部分应用程序。如果您可以将钥匙放在那里，那么它们是安全的。

最后，这是一个经济上的折衷：密钥有多重要，您可以负担多少时间或软件，对密钥感兴趣的黑客有多熟练，他们想要多少时间？花费多少钱，才可以窃取密钥之前的延迟，成功的黑客将在多大程度上分配密钥，等等。像密钥之类的小信息比整个应用程序更难保护。从本质上讲，客户端上的任何内容都是坚不可摧的，但是您当然可以提高标准。

（我是ProGuard和DexGuard的开发人员）

在我看来，只有很少的想法可以保证：

1. 将您的秘密保存在Internet上的某个服务器上，并在需要时将其抓取并使用。如果用户将要使用保管箱，那么没有什么可以阻止您向您的站点发出请求并获取您的密钥。

2. 将您的秘密放入jni代码中，添加一些可变代码以使您的库更大，更难于反编译。您也可以将密钥字符串分成几部分，并放在不同的位置。

3. 使用混淆器，也将代码散列在秘密中，稍后在需要使用时对其进行散列。

4. 将您的秘密密钥作为资产中图像之一的最后一个像素。然后在需要时在代码中阅读它。混淆代码应有助于隐藏将读取该代码的代码。

如果您想快速了解一下阅读apk代码的难易程度，请抓住APKAnalyser：

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

另一种方法是首先不要在设备上拥有秘密！请参阅移动API安全技术（尤其是第3部分）。

使用久负盛名的间接传统，在您的API端点和应用程序身份验证服务之间共享秘密。

当您的客户端想要进行API调用时，它会要求应用程序身份验证服务对其进行身份验证（使用强大的远程证明技术），并且会收到一个由机密签名的有时间限制的令牌（通常是JWT）。

令牌与每个API调用一起发送，端点可以在对请求进行操作之前验证其签名。

实际机密永远不会出现在设备上。实际上，该应用程序永远不会知道它是否有效，它会请求验证并传递生成的令牌。间接带来的好处是，如果您想更改机密，则可以这样做，而无需用户更新其已安装的应用程序。

因此，如果您想保护自己的秘密，那么首先不要在应用程序中拥有它是一个不错的方法。

旧的不安全方式：

遵循3个简单的步骤来保护API /秘密密钥（旧答案）

我们可以使用Gradle来保护API密钥或密钥。

1. gradle.properties（项目属性）：使用键创建变量。

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle（模块：应用程序）：在build.gradle中设置变量以在活动或片段中访问它。将以下代码添加到buildTypes {}中。

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

3.通过应用程序的BuildConfig在活动/片段中访问它：

BuildConfig.GoogleSecAPIKEY

更新：

上述解决方案在开源项目中有助于通过Git进行提交。（感谢David Rawson和riyaz-ali的评论）。

根据Matthew和Pablo Cegarra的评论，上述方法并不安全，反编译器将允许某人使用我们的秘密密钥查看BuildConfig。

解决方案：

我们可以使用NDK来保护API密钥。我们可以将密钥存储在本地C / C ++类中，并在我们的Java类中访问它们。

请关注此博客以使用NDK保护API密钥。

关于如何在Android中安全存储令牌的后续操作

App-Secret密钥应保持私密性-但是在发布应用程序时，某些人可能会将其撤消。

对于那些家伙，它不会隐藏，请锁定任ProGuard一代码。这是一种重构，一些付费混淆器正在插入一些按位运算符以获取jk433g34hg3 String。如果您工作3天，则可以使黑客入侵时间延长5到15分钟：)

最好的方法是保持原样，恕我直言。

即使存储在服务器端（您的PC上），该密钥也可能被黑客破解并打印出来。也许这需要最长的时间？无论如何，最好是几分钟或几个小时。

普通用户不会反编译您的代码。

一种可能的解决方案是对应用程序中的数据进行编码，然后在运行时使用解码（当您要使用该数据时）。我还建议使用progaurd使其难以阅读和理解应用程序的反编译源代码。例如，我将编码密钥放入应用程序中，然后在应用程序中使用解码方法在运行时对我的秘密密钥进行解码：

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

只需在Google中稍作搜索，便可以找到这么多的加密器类。

添加到@Manohar Reddy解决方案中，可以使用firebase数据库或firebase RemoteConfig（默认值为Null）：

1. 加密您的钥匙
2. 将其存储在firebase数据库中
3. 在应用启动时或需要时获取它
4. 解密密钥并使用它

此解决方案有什么不同？

• 没有基础的firebase
• Firebase访问受到保护，因此只有具有签名证书的应用才有权进行API调用
• 加密/解密以防止中间人被拦截。但是已经调用https到firebase

这个例子有很多不同的方面。我将提到一些我认为没有在其他地方明确涵盖的要点。

保护运输中的秘密

首先要注意的是，使用他们的应用程序身份验证机制访问Dropbox API 要求您传输密钥和机密。连接是HTTPS，这意味着您不知道TLS证书就无法拦截流量。这是为了防止人们在从移动设备到服务器的旅程中拦截和读取数据包。对于普通用户而言，这是确保其流量隐私的一种非常好的方法。

它不擅长的是阻止恶意程序下载应用程序并检查流量。使用中间人代理来处理进出移动设备的所有流量确实很容易。由于Dropbox API的特性，在这种情况下，无需反汇编代码或对代码进行反向工程即可提取应用密钥和机密。

您可以进行固定，以检查从服务器收到的TLS证书是否为您期望的证书。这会向客户端添加检查，并使拦截流量更加困难。这将使检查飞行中的流量变得更加困难，但是固定检查发生在客户端中，因此仍然有可能禁用固定测试。它确实使它变得更难。

保护静止的秘密

第一步，使用诸如proguard之类的东西将有助于使其中保存任何秘密的地方变得不那么明显。您也可以使用NDK来存储密钥和机密并直接发送请求，这将大大减少具有适当技能以提取信息的人员。可以通过在任何时间长度内不直接将值存储在内存中来实现进一步的混淆，您可以按照其他答案的建议在使用前对其进行加密和解密。

更多高级选项

如果您现在对将机密放在应用程序中的任何位置都感到不安，并且您有时间和金钱来投资更全面的解决方案，那么您可以考虑将凭据存储在服务器上（假设您拥有任何凭据）。这将增加对API的任何调用的延迟，因为它必须通过服务器进行通信，并且由于数据吞吐量的增加，可能会增加运行服务的成本。

然后，您必须决定如何最好地与服务器通信以确保服务器受到保护。这对于防止内部API再次出现所有相同问题非常重要。我可以给出的最佳经验法则是，不要因为中间人威胁而直接传输任何秘密。取而代之的是，您可以使用机密对流量进行签名，并验证服务器收到的所有请求的完整性。一种标准的方法是计算密钥上键入的消息的HMAC。我在一家拥有安全产品的公司工作，该产品也在该领域中运作，这就是为什么这种东西令我感兴趣的原因。实际上，这是我的一位同事写的一篇博客文章，涵盖了大部分内容。

我应该怎么办？

借助任何此类安全建议，您都需要做出成本/收益决定，以决定让某人闯入它的难度。如果您是一家保护数百万客户的银行，则您的预算与支持他们的应用程序的人完全不同空余时间。阻止某人破坏您的安全性几乎是不可能的，但是实际上，很少有人需要所有的花招，并且通过一些基本的预防措施，您可以走很长一段路。

最安全的解决方案是将密钥保存在服务器上，并通过服务器路由所有需要该密钥的请求。这样，密钥就永远不会离开服务器，因此只要您的服务器是安全的，密钥也就不会离开服务器。当然，此解决方案会降低性能。

firebase database当应用程序启动时，要保守秘密并从中获取秘密，这比调用Web服务要好得多。

无论您采取什么措施来保护您的秘密密钥，都不是真正的解决方案。如果开发人员可以对应用程序进行反编译，则无法确保密钥的安全，隐藏密钥仅仅是模糊性的安全性，而代码混淆也是如此。保护秘密密钥的问题在于，为了保护它，您必须使用另一个密钥，并且还需要保护该密钥。想想隐藏在用钥匙锁的盒子中的钥匙。您将一个盒子放在房间内并锁定房间。您剩下另一把钥匙来保护。而且该密钥仍将在您的应用程序内进行硬编码。

因此，除非用户输入PIN或短语，否则无法隐藏密钥。但是要做到这一点，您将必须有一种方案来管理带外发生的PIN，这意味着要通过不同的渠道。对于保护Google API之类的服务的密钥当然不切实际。

年代久远，但仍然足够好。我认为使用NDK和C ++将其隐藏在.so库中会很好。.so文件可以在十六进制编辑器中查看，但很幸运，反编译：P

保持私有性的唯一真实方法是将它们保留在服务器上，并使应用程序将所有内容发送到服务器，然后服务器与Dropbox进行交互。这样，您就永远不会以任何格式分发私钥。

基于痛苦的经验，并向IDA-Pro专家咨询后，最好的解决方案是将代码的关键部分移至DLL / SharedObject，然后从服务器中获取并在运行时加载。

必须对敏感数据进行编码，因为这样做很容易：

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