现代客户端/服务器身份验证技术答案

【问题标题】：Modern client/server authentication techniques现代客户端/服务器身份验证技术
【发布时间】：2009-12-29 17:24:56
【问题描述】：

我正在构建一个使用 HTTP 进行通信的非浏览器客户端-服务器 (XULRunner-CherryPy) 应用程序。我现在正在思考的领域是用户身份验证。由于我没有丰富的安全知识，因此我更喜欢使用久经考验的方法和现成的库，而不是尝试自己发明和/或构建一些东西。

我最近一直在阅读很多文章，我可以说我留下的只是很多挫败感，其中大部分来自 this 和 this 博客帖子。

我认为我需要的是：

在数据库中安全存储密码（自适应哈希？）
用户凭据的安全有线传输（摘要式身份验证？SSL？）
后续请求的安全令牌身份验证（不确定）

所以问题是：实现这一点的现代（最好是无头痛）技术和/或库是什么？（不会存储敏感信息，例如信用卡号）。

我一直在研究 OAuth，他们有一个强烈推荐使用的新版本。问题是文档仍在开发中，没有库实现新版本 (?)。

【问题讨论】：

标签： python authentication client-server xulrunner

【解决方案1】：

这可能不是一个完整的答案，但我想提供一些关于彩虹表和网络的令人放心的消息。由于以下原因，我不会太担心 Rainbow Tables 与 Web 相关的问题：

(1) Rainbow table 通过检查散列密码来破解工作。在网络上，散列密码存储在您的数据库中，因此即使考虑使用彩虹表，首先需要破解整个数据库。

(2) 如果您像大多数密码存储系统一样使用salt，那么彩虹表很快就会变得不可行。基本上，盐会在给定密码的末尾添加一系列额外的位。为了使用彩虹表，它需要在每个明文密码中容纳额外的位。例如，您向我们展示的第一个链接有一个彩虹表实现，它可以破解多达 14 个字符的密码。因此，如果您有超过 14 个字节的盐，那么该系统将毫无用处。

【讨论】：

感谢您的建议。看起来具有足够长的盐的多次迭代散列将足够安全（即使盐值与散列密码一起存储）。
除了最严格的要求之外，作为存储系统听起来不错。记住要小心密码是如何通过网络发送的，在人们登录时使他们的会话标识符过期，以及困扰 Web 身份验证的所有其他同样重要的安全注意事项。

【解决方案2】：

Amazon Web Services、OpenID 和 OAuth 都有请求签名的示例。 Amazon Web Services 是一个易于遵循的示例，因为围绕交互没有更复杂的协议。它们基本上涉及让客户端或服务器通过使用先前设置的密钥（或密钥对）散列其所有字段来签署请求，并让另一端通过执行相同操作来验证签名。通过在字段中包含 nonce 或时间戳来防止重放哈希。

设置密钥或其他凭据以允许此操作可以通过 SSL 完成，并且应该注意 OAuth WRAP 的动机之一是用 SSL 替换部分或全部此请求签名，以便于实施。

【讨论】：

【解决方案3】：

经过大量探索并尝试基于 Amazon S3 设计（我认为）编写我自己的原型（我认为）非常安全，我发现这个优秀的网站可以回答我所有的问题，一个企业安全 API 工具包，以及更多，更多：OWASP.

【讨论】：