代码之家 › 专栏 › 技术社区 › m_vitaly

我应该如何在服务器上存储加密的用户数据,并只为正确的用户服务?

authorization passwords encryption authentication security

m_vitaly · 技术社区 · 14 年前

假设我必须存储用户的敏感数据,这些数据可以在客户端加密。

加密(可选)应使用用户的口令 .
用户登录(可选)应使用用户的密码 .

笔记:
纯文本密码不会存储在服务器上或通过网络传输。

我的选择及其缺点:

1。没有身份验证,客户端授权:
服务器将数据提供给每个人,但只有原始用户才有解码的手段。
数据可用于 任何人 尝试破解加密-这不是保护加密的最佳方法。

2。服务器端身份验证,无授权:
服务器存储用户访问数据的密码,并且只将数据提供给可以提供正确密码的用户。
用户不信任网络传输其数据 不加密 .

三。认证和授权:
服务器存储用户的密码以访问加密的数据,使用不同于用户密码的密码短语进行加密。
安全性好,但用户不想记住 两个口令 .

4。验证与授权: 服务器存储用户的密码以访问加密的数据,使用相同的密码进行加密。
用户很高兴。一些安全问题。

我更喜欢最新的第四个选项,但我担心的是:
如果服务器受到攻击,我怎么能确保加密的密码和加密的数据不能一起使用来破坏加密呢? 我怎样才能更难破解加密?

一些想法:

对密码和数据使用不同的加密算法。
在加密之前,将固定字符串添加到用户密码的末尾。
将用户密码填充到一定长度。

编辑:

系统应该非常类似于一个从各个方面都应该是安全的备份系统:服务器不应该能够读取数据,只有原始客户机才能访问数据,并且应该防止中间人攻击。因此,如果有人入侵服务器身份验证或客户机加密,则不应显示数据。

它应该是基于网络的,所以中间人的攻击应该通过https来防止。

为了防止服务器黑客泄露数据,数据在客户端加密。

为了防止客户机加密被篡改,应该在服务器端使用一些登录和密码或令牌(可能是唯一的URL)保护对数据的访问。

3 回复 | 直到 8 年前

Giacomo Verticale 14 年前

您可以查看零知识认证协议,特别是 Secure Remote Password protocol 这样就可以在不向服务器透露密码的情况下执行基于密码的身份验证。这样,相同的密码既可以用于身份验证,也可以用于派生数据加密密钥。另外,你可以看看 Clipperz 在线服务,它实现了与您的需求类似的东西,也是开源的。

AviD 14 年前

@重要的是,请允许我在回答之前澄清一些术语,因为您似乎对某些术语使用了不同于常用的含义。

Authentication -证明你是谁的过程(更准确地说,你拥有你声称的身份)。
Authorization -用于限制、控制和授予访问权的机制。
Encryption -一种保护数据的机制,即使对有权访问数据的人也是如此。

现在,请允许我重新表述您的选项,然后我将建议其他内容:

没有身份验证,没有授权,客户端加密
服务器端认证、服务器端授权、服务器端加密
服务器端认证、服务器端授权、客户端加密
服务器端身份验证、服务器端授权、使用服务器凭据的客户端加密。

现在,我觉得每个人的立场都更清晰了。
一般来说,你真的很想遵循“最佳实践”(不要让我开始这些)的原则“纵深防御”,即不要只使用加密,或只使用访问控制,而是同时使用两者!但是,正如您所指出的,这可以是相反的(如果用户需要记住二密码)到另一个原则,“保持安全简单”。

在不太烦人的情况下,你在环境方面没有提供太多信息。例如,这是一个Web应用程序吗?如果是这样,为什么SSL/TLS加密不够?或者这是用户上传您(和您的系统)不应该看到的个人数据的问题(例如备份类型服务)?在这种情况下,客户端加密是必要的…

因此,(最后)我建议的选项,取决于您的环境/要求:

如果可以,请依赖安全协议(如SSL/TLS)进行加密。使用服务器端身份验证+授权、协议加密。
如果您的系统需要进一步保护此数据,例如信用卡(请注意,我目前不是PCI:qsa;),请使用前面的选项,此外,还可以使用服务器生成的加密密钥(而不是密码)进行服务器端加密(当然要保护这一点)。
如果数据需要受到系统的保护,除了服务器端身份验证+授权(我重述过的选项3)之外,还需要进行客户端加密。
但是,您不必强制用户记住其他密码/短语。同样,根据您的环境,您可能可以考虑存储在客户机上的某种形式的密钥,例如用户证书存储/密钥环中的证书,甚至存储在受保护的配置文件中;基于生物特征数据的密钥(不容易,但我已经看到这一点,尽管它有自己的一组问题),带外KEY分布(例如,通过手机)等。这将使您双方都可以使用强密钥,防止服务器访问这些密钥,不需要用户记住两个密钥,并且在不同的上下文中,不会为不同的用途重复使用一个密码。

Omnifarious 14 年前

使用选项1并使数据的URL包含长随机字符串。任何知道随机字符串的人都可以得到数据。当然,只有创建数据的客户机才会立即关闭该URL。

如果有人想给其他人一个可撤销的访问权,允许他们生成一个新的随机URL,并为他们提供一种命名该随机URL并撤销其获取数据的能力的方法。

Capability based security 更容易纠正,更灵活,对用户更有意义。有一个 really excellent YouTube video about capability based security 和A nice website with some essays about it .