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

查看:178
本文介绍了什么是存储用户凭据外部站点(即不使用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.

然而,假设我创建了一个网站,与其他一些第三方网站进行交互;让我们说这个第三方网站提供的,需要用户的凭据(与该站点)进行身份验证的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.

如果我的目标是,比方说,提供了优越的用户界面或通过该第三方提供的服务之上引入额外的功能,那么在我看来,我需要实际存储用户的凭据,不知何故,这样我就可以使用对于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.

有一个正确的方式做到这一点?我最初的想法是存储在某种形式使得它们能够在服务器上进行解密作出API调用第三方服务宗旨,加密的凭据。这意味着,攻击者需要了解的加密/解密,以窃取用户的密码,外部是如何工作的。不过,这似乎并不牵强给我;一个聪明的黑客谁已经有突破了服务器托管我的应用程序可能会能够得到在code和容易弄明白pretty。

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.

所以,这种做法似乎是聊胜于无,但不完全是巨大的。在那里,人们使用其他策略?难道这整个概念(有需要的用户凭证第三方服务进行交互)是不明智的?

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).

更新:只是为了澄清:我知道,在一个理想的世界中,第三方服务将实现(或同等学历)的OAuth的一些版本,这样我就不必存储凭据。不幸的是,在这种情况下,实际情况是,第三方服务需要用户名和密码,每一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认为你应该的的采取的责任的一些地方保存的凭据的文件系统。试想,即使是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天全站免登陆