现代客户端/服务器身份验证技术
我正在构建一个使用 HTTP 进行通信的非浏览器客户端服务器 (XULRunner-CherryPy) 应用程序。我现在正在思考的领域是用户身份验证。由于我在安全方面没有丰富的知识，因此我更喜欢使用经过尝试和测试的方法和现成的库，而不是尝试自己发明和/或构建一些东西。
我最近读了很多文章，我可以说我留下的只是很多挫败感，其中大部分是由 这个 和 此 博客文章。
我认为我需要的是：
- 在数据库中安全存储密码（自适应哈希？）
- 用户凭据的安全有线传输（摘要式身份验证？ SSL？）
- 用于后续请求的安全令牌身份验证（不确定这一点）
所以问题是：什么是现代的（最好是无头痛的）技术和/或库来实现这一点吗？ （不会存储信用卡号等敏感信息）。
我一直在研究 OAuth，他们有一个新的修订版本，强烈建议使用。问题是文档仍在开发中，并且没有库实现新版本（？）。
I'm building a non-browser client-server (XULRunner-CherryPy) application using HTTP for communication. The area I'm pondering now is user authentication. Since I don't have substantial knowledge in security I would much prefer using tried-and-tested approaches and ready-made libraries over trying to invent and/or build something myself.
I've been reading a lot of articles lately and I can say all I have been left with is a lot of frustration, most of which contributed by this and this blog posts.
What I think I need is:
- Secure storage of passwords in the database (adaptive hashing?)
- Secure wire transmission of user credentials (digest authentication? SSL?)
- Secure token authentication for subsequent requests (not sure about this)
So the question is: what are the modern (headache-free preferrably) techniques and/or libraries that implement this? (No sensitive information, like credit card numbers, will be stored).
I've been looking at OAuth and they have a new revision which they strongly recommend to use. The problem is the docs are still in development and there are no libraries implementing the new revision (?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这可能不是一个完整的答案，但我想提供一些有关彩虹表和网络的令人放心的消息。我不会太担心 Rainbow Tables 在网络方面的问题，原因如下：
(1) Rainbow table 通过检查散列密码来破解。在网络上，散列密码存储在您的数据库中，因此即使考虑使用彩虹表，首先需要破解您的整个数据库。
(2) 如果您像大多数密码存储系统一样使用 salt，那么 Rainbow表很快就变得不可行。基本上，盐会在给定密码的末尾添加一系列额外的位。为了使用彩虹表，需要在每个明文密码中容纳额外的位。例如，您向我们展示的第一个链接有一个彩虹表实现，可以破解密码中最多 14 个字符。因此，如果盐的长度超过 14 个字节，那么系统将毫无用处。
This may not be a complete answer, but I would like to offer some reassuring news about rainbow tables and the web. I wouldn't worry too much about Rainbow Tables with regards to the web for the following reasons:
(1) Rainbow table cracks work by examining the hashed password. On the web, the hashed password is stored on your database so to even consider using rainbow tables one would first need to hack your entire database.
(2) If you use a salt as most password storage systems do, then rainbow tables rapidly become unfeasible. Basically a salt adds a series of extra bits to the end of a given password. In order to use a rainbow table, it would need to accommodate the extra bits in each plaintext password. For example the first link you showed us had a rainbow table implementation that could crack up to 14 characters in a password. Therefore if you had more than 14 bytes of a salt that system would be useless.
Amazon Web Services、OpenID 和 OAuth 都有请求签名的示例。 Amazon Web Services 是一个很容易遵循的示例，因为没有更复杂的交互协议。它们基本上涉及让客户端或服务器通过使用先前设置的密钥（或密钥对）对请求的所有字段进行散列来签署请求，并让另一端通过执行相同的操作来验证签名。通过在字段中包含随机数或时间戳来防止重放哈希。
设置密钥或其他凭据以允许此操作可以通过 SSL 完成，并且应该注意的是，OAuth WRAP 的动机之一是用 SSL 替换部分或全部请求签名，以便于实现。
Amazon Web Services, OpenID, and OAuth have examples of request signing. Amazon Web Services is an easy example to follow because there isn't a more complex protocol around the interactions. They basically involve having the client or server sign a request by hashing all of its fields with a previously set up key (or keypair), and having the other end verify the signature by doing the same. Replaying the hash is prevented by including a nonce or timestamp in the fields.
Setting up keys or other credentials to allow this can be done over SSL, and it should be noted that one of the motivation of OAuth WRAP is to replace some or all of this request signing with SSL, for ease of implementation.
经过大量探索并尝试基于 Amazon S3 设计编写自己的原型（我认为）非常安全，我发现了这个优秀的网站，它可以回答我所有的问题，一个企业安全 API 工具包，以及很多很多更多：OWASP。
After a lot of poking around and trying to write my own prototype based on Amazon S3 design which (I thought) was pretty secure, I found this excellent website which has answers to all my questions, an Enterprise Security API Toolkit, and much, much more: OWASP.