这是一个创建于 116 天前的主题，其中的信息可能已经有所发展或是发生改变。
哪怕一次验证需要进行 1s 运算（这个效率已经影响用户体验了） 1000000/3600~=277.778h ，十多天的时间，更别说是可以加机器一起跑
至于拖慢数据库泄露后发现高价值用户的时间，你密码表都能泄露用户数据表大概率也泄露了
 |
2 ryd994 2 月 10 日 via Android 1
是。密码不能只有 6 位。 |
 |
3 wfg 2 月 10 日 via iPhone多次错误会冷却，不存在十多天爆破的情况。 |
 |
4 sentinelK 2 月 10 日没太懂楼主想表达什么，不安全指的是哪一侧？ 如果是用户侧的话，问题不大，因为六位数字往往伴随着尝试次数限制。 但是你光拿到 hash ，你怎么知道他的算法是什么，以及他的明文是什么范围？ |
 |
7 BenHunDun 2 月 10 日其实不是很确定场景是什么, 可能输入 6 位, 但是在后端有加 salt 后再做哈希? |
|
11 sentinelK 2 月 11 日@drymonfidelia 数据库侧，慢哈希的意义是相较于其他算法而言的。 如果是其他算法的话，使用 GPU 加速，那暴力破解的单位将会是毫秒。 |
 |
13 esile 2 月 11 日连续三次错误锁死或者增加锁定间隔时间，这个 faceid 一样，你不可能短时间弄到长一样的人来解锁。 |
 |
15 iamwin 2 月 11 日然而用 6 位数的东西，首先考虑的就是你输错几次以后就锁死，所以不存在给你 10 天爆破的机会的 |
 |
16 restkhz 2 月 12 日简化一下思路，假设跑完耗时 t=单次计算耗时 k 乘字符集的位数次方 但是 k 有上限。能做的有限。而且特别消耗计算资源，可能导致 DoS 。LiveOverflow 曾经有个节目讲到过一点这个。既然有上限，我们这里就先把它当常数了。 你讲的这种情况，假设用 bcrypt ，factor 设置成大概跑 1 秒，3060 跑一个,hashcat 只要几个小时。 然而 10^x,哪怕你字符集是 10 个数字，然而看位数是指数函数，增长速度很快。这就是为什么密码位数非常重要。 |
 |
17 MrYELiex 2 月 26 日慢哈希防御的是拖库以后的离线爆破 这种情况下会增加整个数据库密码被暴力破解的风险 特别是 6 位 pin(传统银行卡支付密码)很容易被爆破 密码表太小了 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。