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

Question

我问一个 这里类似的问题 前一段时间，但所有答案都提供了OpenID，这很好，但它不适用于需要不使用它的身份验证的服务（例如EventBrite）。

假设我想创建一个应用程序，该应用程序列出了事件Brite及其分析（其中包括EventBrite）的应用程序。任何人都可以注册此服务以列出他们的活动。但是，由于EventBrite没有开放验证的验证，因此我需要以某种方式将用户登录和密码输入EventBrite。

一些可能的解决方案是：

1. 在YAML中存放凭据 像这样. 。容易入侵。
2. 将用户输入凭据进入我的网站上的表单，我将凭据保存到我的数据库中，然后使用它们登录到Eventbrite。容易入侵。
3. 让用户输入凭据，然后将它们直接传递给Eventbrite而不保存，然后将响应标头Cookie保存到数据库中，并且在它们到期后，请再次登录。这很容易入侵吗？

这项假设的服务还希望自动检查事件（例如通过CRON），因此不取决于用户通过浏览器访问我的网站。因此，需要将cookie或deligional存储在某个地方。

事情是， 在询问有关机密和安全性的类似问题之后 听起来你应该 绝不 构建一个可以执行我描述的应用程序。一定有一些方法可以构建这样的东西是可以的。

那是什么？我想念什么？可以使用＃3并保存cookie（但是仍然需要用户通过我发送给EventBrite的表单提交电子邮件/密码）吗？什么是可接受的解决方案？

Answer 1

没有安全的方法来做到这一点。您可以使用解决方法，但仅此而已。

1. 将密码存储在YAML或XML中，在ClearText中肯定已经淘汰
2. 实际上，即使加密和存储密码也是错误的。您的应用程序将需要一种解密密码的方法，因此攻击者还可以解密密码。
3. 存储密码的推荐方法是盐 +哈希，但是由于它变得无法恢复，因此在您的情况下是没有用的。
4. 由于2＆3，无论您在何处存储用户凭证，都很容易受到伤害。
5. 存储cookie而不是密码是一个更好的主意。但同样，这涉及通过您网站的密码，这不好。

鉴于您的情况，存储cookie是一种更好的方法。甚至在您的网站上都使用HTTP。不过，它并不理想，您和您的用户应该意识到这一点。

Answer 2

EventBrite最近发布了描述的新文档 如何实现跨站点用户身份验证的OAuth2.0。我建议使用我们的 基于Javascipt的OAuth2.0小部件, ，默认情况下，将用户的身份验证令牌存储在其浏览器的LocalStorage中。由于身材令牌存储在用户的浏览器中，并阻止其他域访问，因此不可能有任何安全泄漏。

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

Answer 3

大多数站点仅支持使用原始clearText密码的直接登录，因此您必须获取，存储并提供。而且我永远不会相信你。您的概念问题在于，您需要将密码提供给第三方。解决方案不涉及第三方，例如，我的浏览器非常擅长自动存储和填充密码（我的硬驱动也受密码受到保护）。而且它们也是其他数十个密码钱包应用程序。我不会通过使用您的服务来订阅任何内容。

在从事这样的业务之前，请考虑您将成为第一目标。 Facebook，Google对安全性，花费大量时间，金钱和精力来确保登录安全非常偏执。您有相同的资源吗？然后，您是一个更好的目标。同样，通过黑客入侵您的服务，他们立即获得了多个帐户，用户的密码，还看到谁总是重复使用密码。

Answer 4

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

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

登录后，用户可以在此处找到其user_key： http://www.eventbrite.com/userkeyapi

这应防止用户名和密码信息通过电线拦截，或从本地数据存储中读取。