2

我们正在为我们的应用程序添加 Dropbox 支持，现在我们有一个“应用程序密钥”和“应用程序机密”。我可以将它们保留为代码中的纯文本，如同步 API 教程中所列：

   DBAccountManager* accountMgr =
    [[DBAccountManager alloc] initWithAppKey:@"hf2hf892hf9y29h" secret:@"n29fh82h4f"];

（注意：这是一个虚构的密钥和秘密，不是我们真正的。）

但是，如果有人愿意，从应用程序中提取它们会非常容易。为了防止这种情况，我们可以添加某种基本加密来使密钥更难找到，但显然密钥仍将在某些时候用于调用 DropBox 客户经理，因此无法完美保存它们安全的。

这是任何人担心的事情，还是真的想进去找出钥匙的人只是生活中的一个事实？

4

3 回答 3

2

这是任何人担心的事情吗

任何理智的开发人员都会担心它。一定要使用某种形式的加密。

提示：我的态度 - 当我从 AppStore 下载一个需要某种形式的登录才能 [在此处插入任意 Web 服务] 的应用程序时，我通常会解密二进制文件并运行otool或至少strings在其上运行。如果其中包含明文密码/OAuth 密钥/SSL 密钥对等，我通常会立即将其丢弃。

真正想进去的人可以进去找出钥匙，这只是生活的事实吗？

实际上，是的，即使钥匙链也不安全 ;-)。但是，如果主题是您的数据和/或用户的安全，这不是不尽力而为的借口。

于 2013-07-19T20:36:19.910 回答
0

首先，你的担心是有道理的。你应该把它放在钥匙串里。

然而，正如Carbonic Acid已经说过的那样，没有什么是绝对安全的，即使是钥匙链也是如此。有时，人们会犯错误，只关注一个安全威胁而忽视另一个更大的问题。这很像优化，（除了分析安全性比分析性能更难）。

你不需要让你的秘密不可能被窃取，只是窃取比在其他地方获取更昂贵。而且 Dropbox API 密钥并不完全是母鸡的牙齿。

于 2013-07-19T22:09:10.147 回答
0

如果其他人偶然发现此问题，则提供更新的答案。

Dropbox API OAuth 2.0 现在具有 PKCE，它不需要客户端密码来生成访问令牌。他们甚至在他们的 oauth 指南中特别概述了这个用例：

如果您的应用是 它应该
需要后台访问的客户端桌面应用程序或移动应用程序 使用带有刷新令牌的 PKCE 的 OAuth 代码流。

如果您查看/oauth2/token API 文档示例，您将看到 PKCE 方法不使用客户端密码。

这个附加指南 - PKCE：什么和为什么？- 提供一些实现它的基本信息。

编辑：

什么时候不适合PKCE？

在 Dropbox 实现的情况下，当您需要在后台访问 Dropbox API（即没有用户交互）时，PKCE 是不合适的。这是因为，不会oauth/token授予您刷新令牌。（刷新令牌用于生成新的访问令牌，无需用户交互）

要在使用 PKCE 时获取刷新令牌，您需要提供token_access_type=offline给oauth2/authorize（类似于他们的代码流）。在这一点上，我不知道为什么他们的指南建议使用刷新令牌的代码流，如果 PKCE 可以在不存储或使用客户端密码的情况下实现相同的效果。

于 2021-05-30T13:51:03.807 回答