在没有 OpenID 的情况下将密码存储到 API 的安全方式？

Question

不久前我问了一个similar question here，但所有的答案都是提供 OpenID，这很好，但它不适用于需要身份验证但不使用它的服务（例如 EventBrite）。

假设我想创建一个应用，列出来自 event brite 的事件及其分析（其中 eventbrite 包括）。任何人都可以注册此服务来列出他们的活动。但由于 EventBrite 没有 OpenID 进行身份验证，我需要以某种方式获取 EventBrite 的用户登录名和密码。

一些可能的解决方案是：

1. 将凭据存储在 YAML like this 中。易于破解。
2. 让用户在我的站点上的表单中输入凭据，我将凭据保存到我的数据库中，并使用它们登录 EventBrite。易于破解。
3. 让用户输入凭据，我直接将它们传递给 EventBrite 而不保存，我将响应标头 Cookie 保存到数据库中，当它们过期时，让他们再次登录。这很容易破解吗？

此假设服务还希望自动检查事件（例如通过 cron），因此它不依赖于用户通过浏览器访问我的网站。所以 cookie 或凭据需要存储在某个地方。

问题是，after asking this similar question about confidentiality and security 听起来你应该永远构建一个执行我所描述的应用程序。必须有某种方法可以构建这样的东西。

那是什么？我错过了什么？可以使用#3 并保存 cookie（但仍需要用户通过我发送给 Eventbrite 的表单提交他们的电子邮件/密码）？什么是可接受的问题解决方案？

Answer 1

没有一种安全的方法可以做到这一点。您可以采用变通方法，但仅此而已。

1. 在 YAML 或 XML 中以明文形式存储密码绝对不可行
2. 事实上，即使加密和存储密码也是错误的。您的应用程序需要一种方法来解密密码，因此攻击者也可以解密密码。
3. 推荐的存储密码的方法是 Salt + Hash，但是因为它变得不可恢复，所以在你的情况下它是没用的。
4. 由于 2 和 3，无论您将用户凭据存储在何处，都容易受到攻击。
5. 存储 cookie 而不是密码是一个更好的主意。但同样，这涉及通过您的网站的密码，这不好。

鉴于您的情况，存储 cookie 是一种更好的方法。始终使用 HTTPS，甚至在您的网站上。虽然它不太理想，但您和您的用户应该意识到这一点。

Answer 2

Eventbrite 最近发布了描述how to implement OAuth2.0 for cross-site user authentication 的新文档。 我建议使用我们的javascipt-based OAuth2.0 widget，它默认将用户的身份验证令牌存储在浏览器的 localStorage 中。 由于身份验证令牌存储在用户的浏览器中，并且不会被其他域访问，因此不太可能存在任何安全漏洞。

此身份验证方案完全避免了对电子邮件和密码组合的需求。

Answer 3

大多数网站仅支持使用原始明文密码直接登录，因此您也必须获取、存储和提供密码。我永远不会相信你。 您的概念的问题是您需要将密码提供给第三方。解决方案是不涉及第三方，例如我的浏览器非常擅长为我自动存储和填写密码（我的硬盘驱动器也受密码保护）。它们也是许多其他密码钱包应用程序。订阅，使用您的服务，我不会获得任何收益。

在进入这样的业务之前，请考虑您将成为第一目标。 Facebook、谷歌对安全性非常偏执，花费大量时间、金钱和精力来确保登录安全。你有同样的资源吗？那么你是一个更好的目标。此外，通过入侵您的服务，他们会立即获得多个帐户、您用户的密码，还可以查看谁总是在重复使用其密码。

Answer 4

为了使用 Eventbrite API，我建议确保所有连接都通过 SSL，并且您使用 user_key 而不是用户名和密码进行身份验证。

有关 Eventbrite API 身份验证的更多信息在这里：http://developer.eventbrite.com/doc/auth/

登录后，用户可以在这里找到自己的user_key：http://www.eventbrite.com/userkeyapi

这应该可以防止用户名和密码信息通过网络被截获，或者从本地数据存储中读取。