密码存储，散列（）与sha-512或crypt（）与河豚（bcrypt）？ [英] Passwords storage, hash() with sha-512 or crypt() with blowfish (bcrypt)?
问题描述
- 从/ dev获取512位每用户盐/ urandom，除了最终的散列外，还存储在用户的数据库记录中
- 从存储在文件系统中的/ dev / urandom中取出512位胡椒。这是每个应用程序的
常量，并且对于每个用户都是相同的 - 然后
hash（'sha512'，$ password。$ salt。$ pepper ，TRUE）
散列和salt以二进制形式存储在数据库中，主要是出于习惯。我认为它在安全性方面没有任何区别。如果有的话，它对于SQL备份稍微不方便，并且使得PHP代码显得稍微复杂一些。
$ b $ <$> $
hash（ ）与SHA-256或SHA-512通常被认为已被bcrypt这几天超过？我相信SHA-2（256/512）仍被认为是密码安全的我可能过度了熵位。这很可能是我的代码中的一个缺陷导致的问题，而不是攻击者从数据库转储中反向设计SHA-2哈希。
但是我应该更新一下我的方法，以便继续使用 crypt（）替换CRYPT_BLOWFISH（我相信这被称为bcrypt，在技术上，blowfish是一种密码而不是哈希算法）？
即使是未来的最佳做法？
我并不特别关心算法的计算花费（在合理范围内）。这只会在创建帐户，更改密码或登录时进行散列和比较时成为一个因素。这些活动只占页面浏览量的一小部分。我猜想越慢越好，如果它使得服务器更难产生，那么它会使攻击者的工作变得更慢以暴力。
干杯，B
如果您可以等到php 5.5，那么会为这个内置的函数提供一些有用的函数：
https://gist.github.com/3707231
到那时，使用crypt - 你可以看看这个新函数的这个向前兼容的端口：
https://github.com/ircmaxell/password_compat
This is my current password hashing procedure in PHP/SQL projects...
- Take 512bits of per-user salt from /dev/urandom, stored in the user's DB record in addition to the final hash
- Take 512bits of "pepper" from /dev/urandom which is stored in the file system. This is a constant per-application and is the same for each user
- Then
hash('sha512', $password.$salt.$pepper, TRUE)
The hash and salt are stored in binary in the DB, mainly out of habit. I don't think it makes any difference in terms of security. If anything it's slightly less convenient for SQL backups and makes the PHP code appear marginally more complex.
Is hash() with SHA-256 or SHA-512 generally considered to have been superceeded by bcrypt these days?
I believe SHA-2 (256/512) is still considered cryptographically secure and I'm probably overdoing the entropy bits. It's far more likely that it would be a flaw in my code that would lead to problems than an attacker reverse-engineering a SHA-2 hash from a DB dump.
But should I update my methodology going forward to use crypt() with CRYPT_BLOWFISH instead (I believe this is referred to as bcrypt, with blowfish technically being a cipher rather than hashing algorithm)?
Even just as future best practice?
I'm not particularly concerned about the computational expense of the algorithms (within reason). This would only ever be a factor when creating accounts, changing passwords or on login when you hash then compare. Those activities make up a small percentage of page views. I guess in a way the slower the better, if it makes a server work harder to generate then it will make an attacker's work slower to brute force.
Cheers, B
If you can wait til php 5.5, there will be some helpful functions for this built in:
https://gist.github.com/3707231
Till then, use crypt - you could look at this forward compatible port of the new functions:
https://github.com/ircmaxell/password_compat
这篇关于密码存储，散列（）与sha-512或crypt（）与河豚（bcrypt）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
