在没有 OpenID 的情况下将密码存储到 API 的安全方法？
不久前我在这里问了一个类似的问题，但所有答案都是提供 OpenID，这很好，但它不适用于需要身份验证但不使用它的服务（例如 EventBrite）。
假设我想创建一个应用程序，列出 eventbrite 中的事件及其分析（其中 eventbrite 包括）。任何人都可以注册此服务来列出他们的活动。但由于 EventBrite 没有 OpenID 进行身份验证，我需要以某种方式获取 EventBrite 的用户登录名和密码。
一些可能的解决方案是：
- 在 YAML 中存储凭据这个。容易被破解。
- 让用户在我网站上的表单中输入凭据，我将凭据保存到我的数据库中，并使用它们登录到 EventBrite。容易被破解。
- 让用户输入凭据，我将它们直接传递给 EventBrite 而不保存，并将响应标头 Cookie 保存到数据库中，当它们过期时，让他们再次登录。这很容易被破解吗？
这个假设的服务还希望自动检查事件（例如通过 cron），因此它不依赖于用户通过浏览器访问我的网站。因此 cookie 或凭证需要存储在某个地方。
问题是，在问了这个类似的问题之后机密性和安全性 听起来您永远不应该构建一个执行我所描述的操作的应用程序。必须有某种方法来构建这样的东西才可以。
那是什么方式？我缺少什么？是否可以选择#3并保存cookie（但仍然需要用户通过我发送给Eventbrite的表格提交他们的电子邮件/密码）？什么是可接受的问题解决方案？
I asked a similar question here a while back but all the answers were offering OpenID which is nice but it doesn't work with services that require authentication that don't use it (such as EventBrite).
Say I want to create an app that lists your events from event brite, and their analytics (which eventbrite includes). Any person can sign up for this service to list their events. But since EventBrite doesn't have OpenID to authenticate, I need to somehow get the user login and password to EventBrite.
Some possible solutions are:
- Store credentials in YAML like this. Easily hackable.
- Have user enter in credentials into a form on my site, I save the credentials to my database, and use them to login to EventBrite. Easily hackable.
- Have user enter in credentials and I pass them directly to EventBrite without saving, and I save the response header Cookies to the database, and when they expire, have them login again. Is this easily hackable?
This hypothetical service also wants to automatically check events (say via cron), so it doesn't depend on the user going to my site via the browser. So cookies or credientials need to be stored somewhere.
The thing is, after asking this similar question about confidentiality and security it sounds like you should never build an application that does what I'm describing. There's got to be some way building something like this is okay.
What is that way? What am I missing? Is it okay to go with #3 and save the cookies (but still needing the user to submit their email/password via a form which I send to Eventbrite)? What is an acceptable solution to the problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
没有安全的方法可以做到这一点。您可以采用解决方法，但仅此而已。
鉴于您的情况，存储 cookie 是更好的方法。始终使用 HTTPS，甚至在您的网站上也是如此。虽然它不太理想，但您和您的用户应该意识到这一点。
There isn't a secure way to do this. You can employ workarounds, but that's about it.
Given your situation, storing the cookie is a better approach. Use HTTPS throughout, even on your website. Its less than ideal though, and you and your users should be aware of it.
Eventbrite 最近发布了新文档，描述如何实现 OAuth2.0 进行跨站点用户身份验证。
我建议使用我们的 基于 javascipt 的 OAuth2.0 小部件，它存储用户的身份验证令牌默认情况下在浏览器的本地存储中。
由于身份验证令牌存储在用户的浏览器中，并且防止其他域访问，因此不太可能存在任何安全漏洞。
此身份验证方案完全避免了对电子邮件和密码组合的需要。
Eventbrite has recently release new documentation describing how to implement OAuth2.0 for cross-site user authentication.
I would recommend using our javascipt-based OAuth2.0 widget, which stores the user's authentication tokens in their browser's localStorage by default.
Since the auth tokens are stored in the user's browser, and are prevented from being accessed by other domains, it's not likely that there would be any security leaks.
The need for email and password combos are completely avoided in this authentication scheme.
大多数网站仅支持使用原始明文密码直接登录，因此您也必须获取、存储和提供该密码。我永远不会相信你。
您的概念的问题在于您要求将密码提供给第三方。解决方案是不涉及第三方，例如我的浏览器非常擅长自动为我存储和填写密码（我的硬盘也受密码保护）。还有数十种其他密码钱包应用程序。我不会通过订阅、使用你的服务获得任何东西。
在进入这样的行业之前，请考虑您将成为第一目标。 Facebook、Google 对安全性极其偏执，花费大量时间、金钱和精力来保证登录安全。你们有同样的资源吗？那么你就是一个更好的目标。此外，通过黑客攻击您的服务，他们会立即获得您用户的多个帐户和密码，并查看谁总是重复使用其密码。
Most sites only support direct login with the original cleartext password, so you have to get, store and provide that too. And I would never ever trust you with that.
The problem with your concept is that you require the password to be given to a third party. The solution is not to involve a third party, for example my browser is pretty good at storing and filling in passwords for me automatically (my hard-drive is password protected too). And they are dozens of other password wallet apps too. I wouldn't gain anything by subscribing, using your service.
Before going into such a business, consider you are going to be the #1 target. Facebook, Google are incredibly paranoid about security, spending a lot of time, money and effort to keep the logins safe. Do you have the same resources? Then you are a better target. Also by hacking your service, they immediately get multiple accounts, passwords of your users, also seeing who is always reusing its password.
对于使用 Eventbrite API，我建议确保所有连接都通过 SSL，并且使用 user_key 而不是用户名和密码进行身份验证。
有关 Eventbrite API 身份验证的更多信息，请参见：http://developer.eventbrite.com/doc/auth /
登录后，用户可以在此处找到他们的 user_key： http://www.eventbrite.com/userkeyapi
这应该可以防止用户名和密码信息通过网络被拦截，或者从本地数据存储中读取。
For working with the Eventbrite API, I'd recommend ensuring that all connections are over SSL, and that you authenticate using a user_key rather than a username and password.
More information about authentication for the Eventbrite API is here: http://developer.eventbrite.com/doc/auth/
After logging in, users can find their user_key here: http://www.eventbrite.com/userkeyapi
This should prevent username and password information from being intercepted over the wire, or read from a local data store.