用于加密种子的 Android 设备/帐户特定 ID

发布于 2024-11-17 05:02:14 字数 832 浏览 5 评论 0原文

这可能是一个负载问题,以前已经以多种形式提出过,但我还没有看到这样的问题,我想了解一些关于如何继续的意见。

我正在开发一个应用程序,需要在设备上存储第三方 Web 服务的凭据。我希望对这些凭据进行加密,但我也不想将种子存储在代码/设备上以防止可能的劫持。该应用程序还支持使用谷歌的云备份功能进行备份,这进一步需要加密。

我的想法是,如果我能找到一个唯一的标识符,就可以用作种子。有一些奇怪的要求使这变得困难。

  1. 对于所有情况下给定的硬件/用户组合,ID 必须是唯一的且相同。
  2. 它不能简单地与设备或用户绑定,它必须是两者的组合。
  3. 无论如何,它都必须可用; Wifi 和蓝牙 MAC 地址是不可能的,因为它们在某些设备关闭时不可用。
  4. 据我所知,TelephonyManager ID(SIM 等)并非在所有设备上都可用。
  5. 据我所知,ANDROID_ID 不会在所有情况下都出现。
  6. 该应用程序将在多个市场(例如亚马逊应用商店)发布,因此不一定存在 Google 帐户。
  7. 进行工厂擦除不应影响用于生成此 ID 的任何内容(这样用户就可以不间断地备份、擦除和恢复)。
  8. 进行 OTA 升级不应影响用于生成此 ID 的任何内容(请参阅上述原因)。
  9. 如果卸载/重新安装后必须重新进行身份验证,也没关系。

我知道这个值显然可以被其他应用程序检索,这就是为什么我打算对其进行哈希处理,并通过应用程序 UID 以及<您在此处的建议>进一步播种。

如果有人觉得这些要求不切实际,我也想听听。

特别是考虑到最近的黑客马拉松,我希望至少能够说“如果有人可以破坏这个,那么你手机上的任何东西都是安全的”。

This may be a loaded questions which has been asked in multiple forms before, but I haven't seen it asked quite this way, and I'd like some opinions on how to proceed.

I'm developing an application which requires storing credentials to third-party web services on the device. I want these credentials to be encrypted, but I also don't want to store the seed in code/on the device to prevent possible hijacking. The app also supports backing up using Googles cloud backup functionality, further necessitating encryption.

My thought was that if I could find a unique identifier, that could be used as the seed. There are a few odd requirements making this difficult.

  1. The ID MUST be the unique AND the same for a given combination of hardware/user in all circumstances.
  2. It cannot be simply tied to a device or user, it must be a combinations of both.
  3. It must be available NO MATTER WHAT; Wifi and Bluetooth MAC addresses are out of the question, as they are unavailable on some devices when they are turned off.
  4. From what I've read, the TelephonyManager IDs (SIM, etc.) aren't available on all devices.
  5. From what I've read, the ANDROID_ID won't be present in all circumstances.
  6. The app will be released in multiple markets (eg. Amazon Appstore), so a Google account won't necessarily be present.
  7. Doing a factory wipe should NOT affect anything used to generate this ID (that way the user can backup, wipe & restore without interruption).
  8. Doing an OTA upgrade should NOT affect anything used to generate this ID (see reason above).
  9. It is OK if they have to reauthenticate after an uninstall/reinstall.

I understand that this value can obviously be retrieved by other applications, which is why I intend to hash it, further seeded by the applications UID as well as <your suggestion here>.

If anyone feels the requirements are unrealistic, I'd like to hear that as well too.

Especially in light of the recent hacking marathons, I want to be able to at least say "If someone can compromise this, nothing on your phone is safe".

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

沉默的熊 2024-11-24 05:02:14

为了确保安全,您的要求是合理的,但正如您所怀疑的那样,它们是不切实际的。 Android 设备支持级别之间存在太多差异,无法使其成为现实。

Your requirements are reasonable to ensure security, however as you seem to suspect, they are unrealistic. There are simply too many differences in levels of Android device support to make it realistic.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文