我在这里询问了我被要求实施的协议，以及它的安全性。因为从一开始就很明显它是狗屎。既然如此，我问：
你们能指点我一些非常简单的登录协议（我在密码系统中是空的）吗？我正在开发应用程序的服务器端和客户端，并且我有自己的消息传递系统，所以我有足够的自由度。
您的建议只有 2 个特殊特征。
简单：这个应用程序要运行的网络并不是特别不安全，我只想避免以纯文本形式发送密码
如果可能的话，不要交换太长的信息。越短越好。
2282 次
5 回答
4
查看质询响应身份验证
- 服务器在登录表单中包含一个随机挑战字符串
- 当您登录时，javascript 对密码进行哈希处理，然后将其与质询进行哈希处理
- 然后服务器执行相同的检查（您的数据库应该存储散列密码，但是这种方法会阻止您有效地使用盐作为该散列，因为您必须广播它）
于 2008-10-10T08:14:21.883 回答
2
三通协议会很方便。基本上，它归结为：
- A 人加密他的密码，并将其发送给 B 人。
- B 人对加密的密码进行加密，并将其发送回 A 人。
- 人 A 将其解密，然后将其发回。
- 人 B 解密它，并以明文形式获取密码。
这样，密码永远不会以明文形式发送，加密密钥也不会发送。它也是一个相对快速的协议，因为它（可能）依赖于非常快的对称加密。
于 2008-10-10T08:14:32.070 回答
2
如果数据库内容落入未经授权的手中，将密码哈希存储在数据库中并不是最佳安全性。没有办法直接反转散列，但是有在线字典（如这里）用于反转散列（密码）单词。
在数据库中，您应该存储以下内容：
md5(login_name + domain_or_appname_salt + password);
中间的盐可以防止多种形式的字典攻击。
在客户端（在浏览器中），您将拥有一个带有用户名和密码的登录表单。一小段 javascript 将散列用户名 + app_salt_ 和密码，因此只有 login_name 和生成的散列被发送到服务器。
现在，明文密码永远不会以明文形式发送到服务器。所以你不应该在这里依赖 HTTPS。
在密码更新表单中可以使用相同的技术。因此服务器永远不知道明文密码。
我希望你能从这个和其他答案中得到一些启发。
快乐黑客！
惠伯特
于 2008-10-12T12:42:28.787 回答
0
如果你的协议在 TCP 上运行，你可以只用明文编写身份验证，然后用 SSL 包装通信。例如，如果您将端口 1234 用于您的协议，则可以关闭服务器上的该端口，并让客户端使用 SSH 对其进行隧道传输。这可以通过编程方式完成，这是一种非常常见的解决方案。
如果您的协议通过 HTTP 运行，您可以使用 HTTPS 以标准方式执行此操作。例如，基于 HTTPS 的基本身份验证对于您指定的需求来说是足够安全的。
另一方面，如果您不想在线发送密码，则需要进行质询响应身份验证。
- 服务器发送随机字符串
- 客户端发送随机字符串 + 密码的哈希
- 服务器验证哈希。
这样做的缺点是密码将在服务器上可用（以纯文本形式加密）。如果您不想在服务器上存储密码，那么您需要回到我的第一个示例。
于 2008-10-10T08:10:50.500 回答
0
SASL是一种安全的身份验证机制。1.5+ 版本的 Java 标准库中提供了对 SASL 的支持。
于 2008-10-10T09:00:39.793 回答