这对社交网络类型的网站是否合理？或者,我将在以后使用($currentYear – 2000)进行非常慢的密码检查.
此外,你如何处理从一年到另一年的轮次数？不会改变轮次改变散列,因此不允许您在2014年从2014年开始检查哈希,因为支票将使用额外的一轮？你每年必须重新计算每一个散列,还是如何正常工作？
话虽如此,我也质疑大多数用法的建议1秒.如果您处理高度敏感的信息,1秒(或更长)可以.但是对于普通网站,我通常建议在0.25到0.5秒之间.在某些情况下,你可以降低,但是我不会没有强烈的理由.
现在,问题本身.当您使用crypt()或password_hash()时,迭代计数以返回散列格式存储.事实上,盐也是如此.所以所有需要计算哈希的信息都包含在它里面！
如果您没有使用这些API(或者我保留的polyfill：password-compat),那么我真的不知道为什么不这样做.不要发明自己的密码加密.不要使用使用本机散列的库(如PHPass),除非您有强烈的理由(由于某些政府合规性原因或与PHP的兼容性).
通常认为bcrypt是今天最强大的哈希格式. SCrypt更强大,但有一些问题,它仍然是非常新的(而且它还不在PHP内核中).所以只要使用bcrypt …
password_hash()api有一个机制,可以让你做你所要求的：password_needs_rehash().基本上,你传递哈希值和你今天使用的选项,它告诉你是否需要重新建立它：
if (password_verify($password,$hash)) {
if (password_needs_rehash($hash,PASSWORD_BCRYPT,['cost' => 14])) {
$hash = password_hash($password);
update_password_in_database($hash);
}
$loggedin = true;
}
阅读RFC for password_hash()有关它的更多信息(我从大量的数据源收集数据,并在RFC中包含引用).
编辑 – 追踪@ AnotherParker的评论：
Criminals don’t stop upgrading their crackingBoxes just because you didn’t upgrade your server. You do need to increase the work parameter over time to thwart offline attacks.
排序为真.嗯,真的,但错过了上面我在说什么.
哈希函数的成本参数是一个时间 – 费力的折衷.您有权衡一些时间,以便为每个散列添加额外的努力.在同一个硬件上,花更多的时间将会产生更多的工作.另一种产生更多工作的方法是获得更快的硬件.
但是建议是测试当前硬件上的哈希函数,并且使它像你可以合理地做的那样昂贵.如果0.5秒是您今天能负担得起的最大值,除非您升级服务器硬件,如何增加成本来帮助您？简而言之,这不会是因为你会破坏你已经确定的最大限制是重要的.
