这个基于不安全 HTTP 的身份验证过程中的安全漏洞是什么？
What is the security flaw in this authentification process over unsecure HTTP?
这里是第一个问题:)
我一直在阅读许多关于如何在没有 https 的网站上安全登录的问题。它们都非常有趣，大多数答案归结为 "Use SSL if you care about security!"。我同意这一点，但我也想知道，这个特定过程有什么缺陷（一个用户（=我），没有会话：密码总是与 <[=36= 的完整内容一起发送]> 标签，替换该文件的当前内容。):
- 服务器向页面发送两个变量：随机令牌 A 和 B=derivedfrom(A)。
- 客户端发回md5(密码+时间戳+B)和A.
- 服务器从A派生B执行与客户端相同的md5hash并匹配服务器和客户端的哈希。
- 服务器允许每个 IP 地址每秒不超过 1 个请求。
假设攻击者知道所有有效的 A 和 B 对，him/her 除了重放攻击（在哈希有效的 100 毫秒时间范围内）和纯粹的运气猜出这个特定时间段的正确哈希值？
当然，攻击者仍然可以尝试所有可能的密码，但是使用 https 不会改变这一点。
我并不是说这对不能使用 https 的网站来说是一个有用的策略，只是想知道是否存在我没有想到的理论缺陷。
如果网站目前没有流量，您将如何强行进入？
这里有几个缺陷：
- 你不应该使用 md5。请使用其他一些哈希算法（例如 sha256）
- 为了执行您所说的操作，服务器需要以明文形式存储密码。这是一种非常糟糕的做法，因为如果你被黑客入侵，所有的密码都会被泄露。相反，您应该存储密码的加盐哈希值。更多信息在这里：https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
- 此方法不可行，因为服务器不可能知道时间戳，除非客户端和服务器的时钟同步到毫秒（不要假设它们会是）。即使时钟完全同步，这仍然行不通。从客户端获取时间戳到数据包到达服务器的时间是可变的，服务器需要确切地知道那个时间。没有正确的时间戳，服务器将无法计算哈希值。删除时间戳将导致重放攻击。
- 执行 man-in-the-middle 攻击的攻击者可以即时更改 HTML（或其他）代码并删除散列函数（假设它是在 JavaScript 中执行的）。然后浏览器将明文传输密码。当然认证会失败，但是攻击者会得到密码。
- 可能还存在其他缺陷，但我相信这些足以使该方法效率低下。
底线：不要使用 HTTP 进行用户身份验证。我还没有听说过任何通过 HTTP 进行安全身份验证的案例。如果 SSL 非常昂贵，您可以只将它用于登录页面。这仍然是一种非常糟糕的做法，因为攻击者可以通过窃取会话 cookie（和其他 man-in-the-middle 攻击）来执行会话劫持，但至少密码不会以这种方式泄露。
您描述的是更大的程序中的一个次要技术细节，您根本没有详细说明。我假设该程序的更大目的是登录？那么交换这个token之后会发生什么呢？用户是否收到某种永久令牌，如 cookie？那么这很容易受到：
- 中间人攻击读取所有通信
- 本地网络数据包嗅探，由 Firesheep attack
著名地宣传
甚至 if（这是一个 large if）这个特定的令牌方案是完美的，整个通信链可以被第三方观察到并且未经授权的用户可以在特权网络位置以明文形式读取所有私人数据（包括识别 cookie）(→ session hijacking)。
这里是第一个问题:)
我一直在阅读许多关于如何在没有 https 的网站上安全登录的问题。它们都非常有趣，大多数答案归结为 "Use SSL if you care about security!"。我同意这一点，但我也想知道，这个特定过程有什么缺陷（一个用户（=我），没有会话：密码总是与 <[=36= 的完整内容一起发送]> 标签，替换该文件的当前内容。):
- 服务器向页面发送两个变量：随机令牌 A 和 B=derivedfrom(A)。
- 客户端发回md5(密码+时间戳+B)和A.
- 服务器从A派生B执行与客户端相同的md5hash并匹配服务器和客户端的哈希。
- 服务器允许每个 IP 地址每秒不超过 1 个请求。
假设攻击者知道所有有效的 A 和 B 对，him/her 除了重放攻击（在哈希有效的 100 毫秒时间范围内）和纯粹的运气猜出这个特定时间段的正确哈希值？
当然，攻击者仍然可以尝试所有可能的密码，但是使用 https 不会改变这一点。
我并不是说这对不能使用 https 的网站来说是一个有用的策略，只是想知道是否存在我没有想到的理论缺陷。
如果网站目前没有流量，您将如何强行进入？
这里有几个缺陷：
- 你不应该使用 md5。请使用其他一些哈希算法（例如 sha256）
- 为了执行您所说的操作，服务器需要以明文形式存储密码。这是一种非常糟糕的做法，因为如果你被黑客入侵，所有的密码都会被泄露。相反，您应该存储密码的加盐哈希值。更多信息在这里：https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
- 此方法不可行，因为服务器不可能知道时间戳，除非客户端和服务器的时钟同步到毫秒（不要假设它们会是）。即使时钟完全同步，这仍然行不通。从客户端获取时间戳到数据包到达服务器的时间是可变的，服务器需要确切地知道那个时间。没有正确的时间戳，服务器将无法计算哈希值。删除时间戳将导致重放攻击。
- 执行 man-in-the-middle 攻击的攻击者可以即时更改 HTML（或其他）代码并删除散列函数（假设它是在 JavaScript 中执行的）。然后浏览器将明文传输密码。当然认证会失败，但是攻击者会得到密码。
- 可能还存在其他缺陷，但我相信这些足以使该方法效率低下。
底线：不要使用 HTTP 进行用户身份验证。我还没有听说过任何通过 HTTP 进行安全身份验证的案例。如果 SSL 非常昂贵，您可以只将它用于登录页面。这仍然是一种非常糟糕的做法，因为攻击者可以通过窃取会话 cookie（和其他 man-in-the-middle 攻击）来执行会话劫持，但至少密码不会以这种方式泄露。
您描述的是更大的程序中的一个次要技术细节，您根本没有详细说明。我假设该程序的更大目的是登录？那么交换这个token之后会发生什么呢？用户是否收到某种永久令牌，如 cookie？那么这很容易受到：
- 中间人攻击读取所有通信
- 本地网络数据包嗅探，由 Firesheep attack 著名地宣传
甚至 if（这是一个 large if）这个特定的令牌方案是完美的，整个通信链可以被第三方观察到并且未经授权的用户可以在特权网络位置以明文形式读取所有私人数据（包括识别 cookie）(→ session hijacking)。