如何通过哈希比较限制 API 键的使用
How to restrict usage of an API key with Hash comparison
我目前在 Android 应用程序中使用 Spotify，但我需要使用 秘密为了刷新令牌等等。我想从我的 Backend 传输秘密到应用程序，所以秘密不驻留在 APK 中，并且在反编译时无法找到。我只读了很多关于在你的应用程序中保护秘密的内容，通过代理等各种方式，只使用你自己的后端，将代码放入应用程序中的本机 C++ 代码 (NDK) 或使用应用程序的哈希来确定是否应用程序正在调用后端，而不是在他的计算机后面试图窃取秘密的某个人。
找到选项：
- 代理：意思是通过我自己的服务器路由，不要那个
- 自己的后端：与代理相同，不希望所有请求都通过我自己的服务
- 本机代码：使用它似乎会减慢反编译器的速度，但不会阻止它们
- 哈希：据我所知，
post 提出了一些我认为很奇怪的事情。它正在检索 SHA-1 并将其传递到网络 header 以验证应用程序正在调用。奇怪的是，当您只是 unzip APK 文件时，运行 printcert (keytool -printcert -file CERT.RSA) 命令将显示 APK 的所有 SHA 和 MD5 哈希值。据我所知，这并非万无一失，因为有人可以获取 APK 文件的哈希值并将其提交到服务器。
还有其他方法可以解决这个问题吗？
人类创造的一切都可以被人类分解——没有完全安全的选择。
尽管如此，您可以尝试的东西很少。
在 SharedPrefs 或文件或数据库中使用 end-to-end encryption to establish a secure connection with you server and then send your secret to your app from your backend. Store secret secured via KeyStore。
您还可以利用基于 Vernam 算法的 one-time pad 密码。它具有绝对的密码强度，因此无法破解。结合 Diffie-Hellman，它可能会提供很好的安全提升。
它仍然可以被破解 - 通过在应用程序处于活动状态并解密秘密时在 root 设备上进行内存扫描，通过中间人攻击等。正如我所说 - 一切都可以被破坏（现在可能除了 Vernam 算法）。
不过不要太在意它 - 犯罪分子很难滥用您的秘密。一般来说，他们甚至不会那么在意这些东西。
希望这个回答能对您有所帮助。
你的问题
I'm currently using Spotify in my Android app, but I am required to use a Secret in order to refresh tokens and such. I would like to transmit the secret from my Backend to the app, so the secret does not reside in the APK and cannot be found when decompiling. I've read a lot only about securing secrets in your app, via various ways like proxies, just using your own backend, putting the code into native C++ code (NDK) in the app or using the Hash of the app to determine whether the app is calling the backend, and not some guy behind his computer trying to steal the secrets.
祝贺你努力理解这个问题，你似乎在很大程度上理解了移动应用程序中的秘密总是可以通过静态二进制分析来提取，但我没有看到任何关于检测的提及框架如：
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
或
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
但还有更多其他人存在，它们都会在 运行 时连接到您的代码并提取您存储在移动应用程序中的任何秘密，无论您存储它有多安全，即使您使用硬件支持的密钥库，运行 在受信任的执行环境中：
Android Hardware-backed Keystore
The availability of a trusted execution environment in a system on a chip (SoC) offers an opportunity for Android devices to provide hardware-backed, strong security services to the Android OS, to platform services, and even to third-party apps.
在某些时候，需要使用从这个密钥库中检索到的秘密来向您的第三方服务发出请求，此时攻击者需要做的就是挂钩对该函数的调用并提取传递给它的秘密。
所以无论你最后做什么，移动应用程序中的秘密总是可以提取的，这只是取决于攻击者的技能组合以及他愿意投入的时间和精力。
话虽如此，这让我想到了我一直建议开发人员不要这样做的观点，即从他们的移动应用程序中调用第三方服务。
从移动应用程序访问第三方服务
Found options:
Proxy: It means routing it through my own server, don't want that
Own backend: Same as proxy, don't want all request to got trough my own service
是的，我了解到您不想使用代理或后端，但这是您必须确保访问第三方服务（在本例中为 Shopify）的最佳机会。
我写了 this article 解释了为什么你不应该从你的移动应用程序中这样做，从我引用的地方：
Generally, all Third Party APIs require a secret in the form of an API key, Access Token or some other mechanism for a remote client to identify itself to the backend server with which it wishes to communicate. Herein lies the crux of the problem of accessing it from within your mobile app, because you will need to ship the required secret(s) within the code (the coloured keys in the above graphic).
Now you may say that you have obfuscated the secret within your code, hidden it in the native C code, assembled it dynamically at runtime, or even encrypted it. However, in the end all an attacker needs to do in order to extract this secret is to reverse engineer the binary with static binary analysis, or hook an instrumentation framework like Frida into the function at runtime which will return the secret. Alternatively an attacker can inspect the traffic between the mobile app and the Third Party API it is connecting to by executing a MitM (man-in-the-middle).
With the secret in their possession, the attacker can cause a lot of damage to an organization. The damage can be monetary, reputational and/or regulatory. Financially, the attacker can use the extracted secret to access your cloud provider and your pay-per-call Third Party APIs in your name, thus causing you additional costs. Further, you may be financially hurt by the exfiltration of data which may be sold to your competitors or used to commit fraud. Reputationally you can be impacted when the attacker uses the extracted secret to post on your behalf on social networks, creating a public relations nightmare. Another reputational damage can occur when an attacker uses the Third Party API and violates its terms & conditions (for example where frequent usage of the API triggers rate limits) such that you get blocked from using the service, creating pain for your end users. Last but not least are regulatory troubles caused when the extracted secret is the only mechanism of protecting access to confidential information from your Third Party API. If the attacker can retrieve confidential information such as Personal Identifiable Information (PII), regulatory fines connected to violations of GDPR in Europe, or the new CCPA Data Privacy Law in the California, may be enforced against your business.
So the take home message is that any secret you ship in your code must be considered public from the moment you release your app or push the code to a public repository. By now it should be clear that the best approach is to completely avoid accessing Third Party APIs from within a mobile app; instead you should always delegate this access to a backend you can trust and control, such as a Reverse Proxy.
你现在可能会说问题刚刚从移动应用程序转移到反向代理或后端服务器上，这是一件好事，因为后端或反向代理在你的控制之下，但移动应用程序却出局了你的控制，因为它在客户端，因此攻击者可以用它做任何他想做的事。
在后端或反向代理中，您不会将访问第三方服务的秘密暴露给 public，并且攻击者想要代表您针对该第三方服务进行的任何滥用都需要通过你控制的地方，因此你可以应用尽可能多的防御机制，并且法律要求你的用例。
深度安全
putting the code into native C++ code (NDK)
当隐藏在原生 C 代码中的秘密时，静态二进制分析不容易找到它，至少对于脚本孩子和季节性黑客来说，它需要大多数人可能没有的更好的技能，因此我强烈推荐您可以将其用作额外的安全层，但要保护秘密以访问您自己的服务，而不是我之前提到的第三方服务。
如果您真的决定听从我的建议并将您的努力转移到您可以控制的地方来保护第三方机密，例如您自己的后端，那么我建议您阅读 问题 如何保护移动应用程序的 API REST？ 有关 保护 API 服务器 和 [=80= 的部分]一个可能更好的解决方案。
如果您阅读了上面的答案，那么您已经意识到，如果您在后端保留对第三方服务的访问权限，您可以将 API 服务器锁定到您的移动应用程序，具有很高的安全性。通过使用移动应用证明概念来增强信心。
您想加倍努力吗？
我看你消息灵通，所以你已经知道我要分享的内容了，但是在我对安全问题的任何回复中，我总是喜欢引用 OWASP 基金会的优秀工作，因此如果你允许我在这里做:)
对于移动应用程序
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
我目前在 Android 应用程序中使用 Spotify，但我需要使用 秘密为了刷新令牌等等。我想从我的 Backend 传输秘密到应用程序，所以秘密不驻留在 APK 中，并且在反编译时无法找到。我只读了很多关于在你的应用程序中保护秘密的内容，通过代理等各种方式，只使用你自己的后端，将代码放入应用程序中的本机 C++ 代码 (NDK) 或使用应用程序的哈希来确定是否应用程序正在调用后端，而不是在他的计算机后面试图窃取秘密的某个人。
找到选项：
- 代理：意思是通过我自己的服务器路由，不要那个
- 自己的后端：与代理相同，不希望所有请求都通过我自己的服务
- 本机代码：使用它似乎会减慢反编译器的速度，但不会阻止它们
- 哈希：据我所知，
unzipAPK 文件时，运行 printcert (keytool -printcert -file CERT.RSA) 命令将显示 APK 的所有 SHA 和 MD5 哈希值。据我所知，这并非万无一失，因为有人可以获取 APK 文件的哈希值并将其提交到服务器。
还有其他方法可以解决这个问题吗？
人类创造的一切都可以被人类分解——没有完全安全的选择。
尽管如此，您可以尝试的东西很少。
在 SharedPrefs 或文件或数据库中使用 end-to-end encryption to establish a secure connection with you server and then send your secret to your app from your backend. Store secret secured via KeyStore。
您还可以利用基于 Vernam 算法的 one-time pad 密码。它具有绝对的密码强度，因此无法破解。结合 Diffie-Hellman，它可能会提供很好的安全提升。
它仍然可以被破解 - 通过在应用程序处于活动状态并解密秘密时在 root 设备上进行内存扫描，通过中间人攻击等。正如我所说 - 一切都可以被破坏（现在可能除了 Vernam 算法）。
不过不要太在意它 - 犯罪分子很难滥用您的秘密。一般来说，他们甚至不会那么在意这些东西。
希望这个回答能对您有所帮助。
你的问题
I'm currently using Spotify in my Android app, but I am required to use a Secret in order to refresh tokens and such. I would like to transmit the secret from my Backend to the app, so the secret does not reside in the APK and cannot be found when decompiling. I've read a lot only about securing secrets in your app, via various ways like proxies, just using your own backend, putting the code into native C++ code (NDK) in the app or using the Hash of the app to determine whether the app is calling the backend, and not some guy behind his computer trying to steal the secrets.
祝贺你努力理解这个问题，你似乎在很大程度上理解了移动应用程序中的秘密总是可以通过静态二进制分析来提取，但我没有看到任何关于检测的提及框架如：
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
或
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
但还有更多其他人存在，它们都会在 运行 时连接到您的代码并提取您存储在移动应用程序中的任何秘密，无论您存储它有多安全，即使您使用硬件支持的密钥库，运行 在受信任的执行环境中：
Android Hardware-backed Keystore
The availability of a trusted execution environment in a system on a chip (SoC) offers an opportunity for Android devices to provide hardware-backed, strong security services to the Android OS, to platform services, and even to third-party apps.
在某些时候，需要使用从这个密钥库中检索到的秘密来向您的第三方服务发出请求，此时攻击者需要做的就是挂钩对该函数的调用并提取传递给它的秘密。
所以无论你最后做什么，移动应用程序中的秘密总是可以提取的，这只是取决于攻击者的技能组合以及他愿意投入的时间和精力。
话虽如此，这让我想到了我一直建议开发人员不要这样做的观点，即从他们的移动应用程序中调用第三方服务。
从移动应用程序访问第三方服务
Found options:
Proxy: It means routing it through my own server, don't want that Own backend: Same as proxy, don't want all request to got trough my own service
是的，我了解到您不想使用代理或后端，但这是您必须确保访问第三方服务（在本例中为 Shopify）的最佳机会。
我写了 this article 解释了为什么你不应该从你的移动应用程序中这样做，从我引用的地方：
Generally, all Third Party APIs require a secret in the form of an API key, Access Token or some other mechanism for a remote client to identify itself to the backend server with which it wishes to communicate. Herein lies the crux of the problem of accessing it from within your mobile app, because you will need to ship the required secret(s) within the code (the coloured keys in the above graphic).
Now you may say that you have obfuscated the secret within your code, hidden it in the native C code, assembled it dynamically at runtime, or even encrypted it. However, in the end all an attacker needs to do in order to extract this secret is to reverse engineer the binary with static binary analysis, or hook an instrumentation framework like Frida into the function at runtime which will return the secret. Alternatively an attacker can inspect the traffic between the mobile app and the Third Party API it is connecting to by executing a MitM (man-in-the-middle).
With the secret in their possession, the attacker can cause a lot of damage to an organization. The damage can be monetary, reputational and/or regulatory. Financially, the attacker can use the extracted secret to access your cloud provider and your pay-per-call Third Party APIs in your name, thus causing you additional costs. Further, you may be financially hurt by the exfiltration of data which may be sold to your competitors or used to commit fraud. Reputationally you can be impacted when the attacker uses the extracted secret to post on your behalf on social networks, creating a public relations nightmare. Another reputational damage can occur when an attacker uses the Third Party API and violates its terms & conditions (for example where frequent usage of the API triggers rate limits) such that you get blocked from using the service, creating pain for your end users. Last but not least are regulatory troubles caused when the extracted secret is the only mechanism of protecting access to confidential information from your Third Party API. If the attacker can retrieve confidential information such as Personal Identifiable Information (PII), regulatory fines connected to violations of GDPR in Europe, or the new CCPA Data Privacy Law in the California, may be enforced against your business.
So the take home message is that any secret you ship in your code must be considered public from the moment you release your app or push the code to a public repository. By now it should be clear that the best approach is to completely avoid accessing Third Party APIs from within a mobile app; instead you should always delegate this access to a backend you can trust and control, such as a Reverse Proxy.
你现在可能会说问题刚刚从移动应用程序转移到反向代理或后端服务器上，这是一件好事，因为后端或反向代理在你的控制之下，但移动应用程序却出局了你的控制，因为它在客户端，因此攻击者可以用它做任何他想做的事。
在后端或反向代理中，您不会将访问第三方服务的秘密暴露给 public，并且攻击者想要代表您针对该第三方服务进行的任何滥用都需要通过你控制的地方，因此你可以应用尽可能多的防御机制，并且法律要求你的用例。
深度安全
putting the code into native C++ code (NDK)
当隐藏在原生 C 代码中的秘密时，静态二进制分析不容易找到它，至少对于脚本孩子和季节性黑客来说，它需要大多数人可能没有的更好的技能，因此我强烈推荐您可以将其用作额外的安全层，但要保护秘密以访问您自己的服务，而不是我之前提到的第三方服务。
如果您真的决定听从我的建议并将您的努力转移到您可以控制的地方来保护第三方机密，例如您自己的后端，那么我建议您阅读
如果您阅读了上面的答案，那么您已经意识到，如果您在后端保留对第三方服务的访问权限，您可以将 API 服务器锁定到您的移动应用程序，具有很高的安全性。通过使用移动应用证明概念来增强信心。
您想加倍努力吗？
我看你消息灵通，所以你已经知道我要分享的内容了，但是在我对安全问题的任何回复中，我总是喜欢引用 OWASP 基金会的优秀工作，因此如果你允许我在这里做:)
对于移动应用程序
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.