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

我正在构建使用HTTP进行通信的非浏览器客户端服务器（XULRunner-CherryPy）应用程序。我现在琢磨的区域是用户认证。由于我对安全性缺乏实质性知识，我更倾向于使用经过验证的方法和现成的图书馆来试图自己创造和/或构建某种东西。现代客户端/服务器身份验证技术

最近我一直在阅读很多文章，我可以说我留下的所有内容都是很多挫折感，其中大部分由this和this贡献。

我想我需要的是：

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

所以问题是：什么是现代（无头痛优先）技术和/或库实现t他？（不会存储敏感信息，如信用卡号码）。

我一直在看OAuth，他们有一个新的版本，他们强烈建议使用。问题是文档仍在开发中，没有实现新版本（？）的库。

来源

2009-12-29 vit

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

来源

2010-03-01 16:58:34 vit

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

（1）彩虹表通过检查散列密码破解工作。在网络上，哈希密码存储在您的数据库，所以甚至考虑使用彩虹表，第一个需要破解你的整个数据库。（2）如果您使用salt与大多数密码存储系统一样，那么彩虹表很快就变得不可行。基本上，盐会在给定密码的末尾添加一系列额外的位。为了使用彩虹表，它需要在每个明文密码中容纳额外的位。例如，您向我们展示的第一个链接有一个彩虹表实现，可能会在密码中破解14个字符。因此，如果你有超过14个字节的盐，这个系统将毫无用处。

来源

2010-01-03 09:14:55 Clueless

感谢您的建议。看起来像多重迭代哈希与足够长的盐将足够安全（即使盐值与散列密码一起存储）。 – vit 2010-01-04 11:39:18

对于除最严格要求之外的所有应用程序，这听起来都不错。切记要小心如何通过线路发送密码，在用户登录时过期使用会话标识符，以及所有其他同样重要的安全考虑因素，这些都会影响Web认证。 – Clueless 2010-01-04 14:03:16

Amazon Web Services，OpenID和OAuth提供了请求签名的示例。亚马逊网络服务是一个简单的例子，因为在交互过程中没有更复杂的协议。它们基本上涉及让客户端或服务器通过用先前设置的密钥（或密钥对）对所有字段进行散列处理来签名请求，并且另一端通过相同的方式验证签名。通过在字段中包含一个随机数或时间戳来防止散列。

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

来源

2010-01-06 23:11:34

谢谢，我现在正在查看AWS文档。 – vit 2010-01-07 23:57:09

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

回答

相关问题