nginx 接受的用于 HTTP 基本身份验证的每种哈希格式是否都对暴力破解很弱?

信息安全 哈希 http nginx
2021-08-23 16:58:41

根据http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html nginx 可以读取这些类型的密码哈希:

crypt()、apr1、SHA1 和 SSHA。

这就是我如何理解这些哈希是如何工作的以及它们的问题是什么:

crypt() 丢弃第 8 个字符之后的所有内容,所以如果我的密码是,12345678UltraSecurePa$$w0rd我可以通过键入成功登录12345678这不会破坏强(长)密码的目的吗?如今,暴力破解 8 个字符的密码似乎是微不足道的。我不明白为什么 crypt 应该比明文更安全。

apr1 是 MD5 但减慢了一千倍这些天仍然很弱。人们可以找到关于使用几个 GPU 每秒通过 > 300.000.000.000(3000 亿)哈希值进行暴力破解的报告

SHA1 并不比 MD5 好多少。它是一种经过优化的哈希算法,速度很快,因此容易受到暴力攻击。此外,在这种情况下它不加盐。

最后一种方法是盐渍SHA1。这似乎是在 nginx 中散列 http 基本身份验证密码的最不弱的方法。但是当有人窃取散列时,他也有盐(盐只是base64编码),所以SSHA仍然存在使用快速散列算法“加密”密码的弱点。

nginx 不能使用 bcrypt 或 PBKDF2。

总结一下:如果我希望我的 HTTP 基本身份验证哈希是“安全的”(安全意味着破解哈希的时间太长),我必须遵循以下规则:

  1. 永远不要使用地穴。
  2. 强制使用至少 16 个字符的密码,因为这似乎足以抵御暴力攻击(让我们暂时忽略字典攻击)。

并且:说服 nginx 人,他们应该为 HTTP 基本身份验证实现更好的散列方法。

我的结论有错误吗?

1个回答

这个我自己没有测试过,但是看了Nginx的源码,好像直接用了libc的crypt()函数。根据您的操作系统,您可能有一个健全的 crypt() 实现可用,bcrypt 或 glibc 的 SHA-256/SHA-512 方案。值得一试,看看您是否可以将它与 Nginx 一起使用。