什么是为外部站点(不使用 OAuth)存储用户凭据的智能方法? [英] What's a smart way of storing user credentials for an external site (that does not use OAuth)?

查看:41
本文介绍了什么是为外部站点(不使用 OAuth)存储用户凭据的智能方法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我意识到一般来说,您不应该直接(即以纯文本形式)存储用户凭据;相反,最好存储它们的某种加密形式.

I realize that in general, you should not store user credentials directly (i.e., in plain text); rather, it is best to store some encrypted form of them.

但是,假设我创建了一个与其他 3rd 方站点交互的网站;假设这个第 3 方站点提供了一个 API,该 API 需要用户的凭据(使用该站点)进行身份验证.

However, suppose I create a website that interacts with some other 3rd party site; and let's say this 3rd party site offers an API that requires the user's credentials (with that site) for authentication.

如果我的目标是,比方说,在第三方提供的服务之上提供卓越的 UI 或引入附加功能,那么在我看来,我需要以某种方式实际存储用户的凭据,以便我可以使用API——不是用于我的站点的用户密码(我可以散列和加盐),而是用于外部站点.

If my goal is to, say, provide a superior UI or introduce additional functionality on top of the services provided by this 3rd party, then it seems to me I need to actually store the user's credentials somehow so that I can use the API—not the user's password for my site (I can hash & salt that one), but for the external site.

有没有正确"的方法来做到这一点?我最初的想法是以某种形式存储加密的凭据,以便它们可以在服务器上解密,以便对 3rd 方服务进行 API 调用.这意味着攻击者需要了解加密/解密的工作原理才能窃取用户的外部密码.然而,这对我来说似乎并不牵强.一个已经攻破了托管我的应用程序的服务器的聪明黑客可能能够获取代码并很容易地弄清楚.

Is there a "right" way to do this? My initial thinking is to store the credentials encrypted in some form such that they can be decrypted on the server for purposes of making API calls to the 3rd party service. This would mean that an attacker would need to understand how the encryption/decryption works in order to steal the user's external passwords. However, that does not seem so far-fetched to me; a clever hacker who had already breached the server hosting my application would probably be able to get at the code and figure it out pretty easily.

所以,这种方法似乎总比没有好,但也不是很好.人们是否使用其他策略?整个概念(与需要用户凭据的 3rd 方服务交互)是否不明智?

So, that approach seems like better than nothing but not exactly great. Are there other strategies that people use? Is this entire concept (interacting with a 3rd party service requiring user credentials) ill-advised?

我必须相信至少有一些合理安全的方法来处理这种情况,因为即使在一些相当知名的网站(例如 Mint.com)中,这种情况似乎也相对普遍.

I have to believe there is at least some reasonably secure way of dealing with this situation since it seems relatively common among even some fairly high-profile websites (e.g., Mint.com).

更新:澄清一下:我知道在理想情况下,第 3 方服务将实现某个版本的 OAuth(或等效版本),这样我就不必存储凭据.不幸的是,这种情况下的实际情况是,第 3 方服务要求在每个 API 请求中都发送用户名和密码.那么,我听到的共识是,在这种情况下,大多数开发人员只会拒绝使用该服务(并且很可能会建议他们实施 OAuth)?

Update: Just to clarify: I am aware that in an ideal world, the 3rd party service would implement some version of OAuth (or an equivalent) so that I would not have to store credentials. Unfortunately, the reality in this case is that the 3rd party service requires user name and password to be sent in every API request. So is the consensus that I'm hearing, then, that in this case most developers would just refuse to use the service (and most likely suggest to them that they implement OAuth)?

推荐答案

IMO 认为您应该负责将凭据存储在的某处em> 文件系统.想想即使是第 3 方服务器也知道用户凭据(会存储密码的哈希值,而不是存储的实际密码).
我建议将它们存储为 http 会话的一部分,只要会话处于活动状态,该会话就会持续.

IMO opinion you should not take responsibility to store the credentials somewhere on your file system. Just think that even the 3-rd party server does not know the user credentials (would have the hash of the password and not the actual password stored).
I would recommend to store them as part of an http-session which lasts as long as the session is active.

这篇关于什么是为外部站点(不使用 OAuth)存储用户凭据的智能方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆