我假设用户 ID 在 2 ^{32 个}可能的 32 位值中随机且均匀地归属。在这种情况下，攻击者能做的最好的事情就是以任意顺序尝试潜在的用户 ID（32 位值），直到找到合适的用户 ID。如果有N个有效用户 ID，那么攻击者需要执行的平均尝试次数将接近2 ³² /(N+1)：如果有 1000 个用户，那么攻击者需要连接大约 4在被授予访问权限之前访问您的服务器一百万次。一旦攻击者获得访问权限，他就可以随意重复使用该 ID。

在这种情况下，您唯一的防御措施是尝试检测这种暴力破解，例如通过禁止来自太多失败尝试的 IP 地址。这有局限性；特别是，当许多人使用某种 Web 代理或NAT时，从您的角度来看，他们可能共享相同的 IP 地址，因此您可能会使用锁定策略禁用丢失的用户。相反，攻击者可以租用僵尸网络，以便从许多不同的 IP 地址执行他们的一次性暴力破解。

一种看待它的方法确实是将用户 ID 视为某种密码。在这种情况下，攻击者可以同时攻击所有用户的密码。因此，当用户越多时，安全级别就会降低，如上面的数学表达式所示：更多的用户意味着攻击者的目标更多，而不会增加搜索成本。

登录+密码策略是大多数人所做的。这要好得多：当尝试暴力破解密码时，攻击者必须选择一个特定的用户名，并且只能破解该特定密码。“用户名”是特定于每个用户的非秘密信息。有了用户名，当有一千个用户时，攻击者的任务就不再简单一千倍了。至于“会话令牌”，嗯，有几种或多或少等效的方法（URL 中的令牌，作为 POST 参数的令牌，作为 HTTP 标头的令牌 - 也称为“cookie” - 和很快）; SSL 本身有自己的会话概念，您可以重用它。

总结：没有用户名策略的“秘密用户ID”可以是安全的，但前提是可能的用户ID的空间足够大以击败暴力破解，即使有很多有效的用户ID。这需要大的用户ID，必须随机且统一地选择。128 位就足够了。64位会让我很紧张。32位太小了。

简单的论点是 32 位完全在蛮力限制范围内，这取决于每秒可能进行多少次攻击，搜索整个空间可能需要一周到一年的时间。将该时间除以用户数量，您就有了攻击者找到一个帐户的大致时间范围。

我不知道实现的细节，每个 IP 登录请求的限制使攻击更难，但可能还不够难。是否可以仅通过查看公共代码来推断 ID 空间？现在你最强的防御可能是没有多少人知道所有的用户 ID 都是整数。这不是我要依赖的东西，但是没有整数知识的字典暴力攻击会困难得多。

此外，首先编写此代码的人显然不是很注重安全，似乎可能还有其他问题。跨站点请求伪造、SQL 注入，甚至可能是一些带有老式缓冲区欠载的“快速”C 代码。