安全存储需要用作纯文本的 API 凭证答案

【问题标题】：Securely storing API credentials which need to be used as plain text安全存储需要用作纯文本的 API 凭证
【发布时间】：2013-01-24 14:24:21
【问题描述】：

我创建了一个应用程序，作为 2 个不同 API（WebEx 和 Exchange Web 服务）和电子邮件之间的桥梁。用户向一个特殊的电子邮件地址发送日历邀请，该应用程序解析 ICS 并创建一个 WebEx 会议，然后连接到 Exchange Web 服务并将 WebEx 邀请信息放入原始邀请中。

这是因为 WebEx 没有 Mac 电子邮件/日历集成而创建的。

问题在于，要使用 WebEx API 和 Exchange API，我显然需要这两个 API 的凭据。我使用 AES 256 位加密将凭据安全地存储在数据库中，但要访问 API，我需要原始纯文本凭据（API 中不支持 oAuth 或令牌）。当然，它们是通过 SSL 安全传输的。

安全风险不在于密码被盗，因为加密密钥是安全存储的。我希望解决的问题是，客户担心他们的企业凭据现在以一种允许有权访问这些密钥的人（我或开发团队中的某个人）解密他们的信息并获得对凭据的访问权的方式存储。 .

该应用的价值非常高——它可以节省大量时间，但我如何才能避免这种恐惧，同时仍然允许这种方法发挥作用？

【问题讨论】：

您的服务器是否打电话回家并传递凭据？如果不是，我不明白为什么客户会认为他们输入并存储在设备上的数据可供其他任何人使用。
凭据在网络应用程序使用的数据库中存储、加密。收到电子邮件后，将对其进行处理，然后使用这些存储的凭据通过 WebEx 和 Exchange API 代表用户执行操作。

标签： security

【解决方案1】：

现实情况是，如果您的代码需要发送密码，那么如果开发人员拥有源代码和加密密码，他们就可以访问纯测试密码。解决此问题的唯一方法是拒绝开发团队访问加密密码，并拒绝拥有加密密码的人员访问源代码。您可以通过让开发团队远离生产数据库来实现这一点。

安全风险在于您可以访问存储密钥的生产数据库。消除该访问权限并消除他们的担忧。提供可用于配置密钥的实用程序（桌面或基于 Web） - 无论如何都是个好主意，因为将来需要更改这些密码。

让客户创建一个数据库，然后通过更改连接字符串将应用程序指向该数据库。客户可以使用该实用程序设置密码。

【讨论】：