CRYPT_SHA512 的迭代是否与 bcrypt 一样强大（以及相关问题）
我正在编写用户登录系统的第一次尝试，并希望能做到正确。我觉得我在这里处于重复的领域，但尽管我阅读了所有内容，但仍无法找到一些问题的可靠答案。但是，如果我错过了某些内容，请随时为我指出正确的方向。
我将对所有密码使用 128 位每个用户盐，并强制使用“强”（我知道是主观的！）密码，但无法找出对它们进行哈希处理的最佳方法，因此，
会使用
CRYPT_SHA512进行迭代 和使用一样强大CRYPT_BLOWFISH？有有什么区别 CRYPT_SHA512 与之间 迭代和重复hash_hmac使用sha512a（大） 次数。有一个比 另一个是推荐的 用于散列密码？我问是因为 我正在使用 Kohana 和默认值auth实现使用hash_hmac。我认为不会 很难添加迭代 那（我将不得不 修改它以添加每个用户的盐 无论如何），这让我想到..是否有一个模块可以做到这一点 小哈纳（3.1）？在我开始写我的文章之前 自己的，如果那里有什么东西 这很合适，我很乐意使用 那。所以，执行的东西 哈希拉伸（无论是 bcrypt 还是 sha512）并允许每个用户盐。 最后，
...正如评论中所指出的，问题 4 实际上是一个完全独立的问题，所以我要摆脱它。请随意忽略它。我不会完全编辑它的唯一原因是它已经在答案中引用了。
4. 我的系统将允许用户具有不同的权限。 有些将成为管理员 完全权利，一些开发商拥有 一路上权利稍微少一些 直至有权限的匿名用户 例如，只留下评论。 我还没找到任何 确实有这方面的信息。什么 是存储用户的“正确”方式 数据库中的帐户类型。一个 天真的第一个想法就是一个简单的 用户表中的整数将 足够了，但我忍不住想 这是一个非常糟糕的主意。如果 有人掌握了数据库 不难找出哪个 int 代表管理员， 那么他们只需要暴力 一个密码即可获得完全访问权限 权利。简单地就足够了 哈希帐户类型整数和 存储它，或者我应该寻找 用另一种方法？
I'm writing a first attempt at a user login system and would like to get it right. I feel I'm in duplicate territory here but for all my reading haven't been able to find a solid answer to a few questions. If I've missed something however, please feel free to point me in the right direction.
I will be using 128bit per user salts on all passwords, and enforcing "strong" (subjective I know!) passwords but can't work out what is the best way to hash them so,
Would using
CRYPT_SHA512with iterations ever
be as strong as usingCRYPT_BLOWFISH?Is there aWhat is the difference
between CRYPT_SHA512 with
iterations, and repeatinghash_hmacusingsha512a (large)
number of times. Is one better than
the other and which is recommended
for hashing passwords? I ask because
I'm using Kohana and the defaultauthimplementation useshash_hmac. I don't think it will
be too hard to add iterations to
that (and I'm going to have to
modify it to add per user salts
anyway), which leads me on to ..Is there a module to do this already available for
Kohana (3.1)? Before I go about writing my
own, if there's something out there
that is suitable I'd be happy to use
that. So, something that performs
hash stretching (be it bcrypt or
sha512) and allows per user salts.
And finally,
... as pointed out in comments, question 4 is really a separate question entirely so I'm getting rid of it. Feel free to ignore it. The only reason I won't edit it out completely is that it is already referenced in an answer.
4. My system will allow users with different privileges.
Some will be administrators with
full rights, some developers with
slightly lesser rights, all the way
down to anonymous users with rights
to only leave comments for example.
I haven't been able to find any
information about this really. What
is the "correct" way to store a user
account type in the database. A
naive first thought is that a simple
integer in the user table would
suffice, but I can't help thinking
this is a terribly bad idea. If
someone gets hold of the database it
wouldn't be hard to work out whichint represents an administrator,
then they only need to brute force
one password to gain full access
rights. Would it suffice to simply
hash the account type integer and
store that, or should I be looking
at another method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题1-3的答案实际上是一个答案，由几个部分组成。
首先，您应该使用带有每个用户盐的强哈希。我特别建议使用 PBKDF2，这是一个对此很有用的系统。这包括迭代。
您对 bcrypt 的引用有点不同。密码应始终进行单向哈希处理。您可以使用 PBKDF2 或 hmac 等函数来执行此操作。您不应该使用可逆算法。 但是最好将盐存储在远离哈希本身的地方。这样做的一个建议是使用从文件系统而不是数据库访问的密钥对盐进行加密。最好是在一个具有 600 权限的文件中，该文件由 Web 服务器用户以外的其他人拥有并由 setuid 等加载。这样，即使数据库遭到破坏，仍然没有足够的信息来派生密码。
第 4 部分是关于存储 ACL 的数据结构。有很多选项，因此请四处寻找适合您的选项。您可能不需要完整的 ACL，而只需要用户角色/组或特定权限标志。这将取决于您的应用程序。
The answer to questions 1-3 is really one answer, composed of several parts.
Firstly, you should be using a strong hash with per-user salts. In particular I would suggest PBKDF2 which is a useful system for this. That includes iteration.
Your reference to bcrypt is a bit different. Passwords should always be one-way hashed. You can use a function like PBKDF2 or a hmac to do this. You shouldn't use a reversible algorithm. However it is best if you can store the salt away from the hash itself. One suggestion for doing this is to bcrypt the salt with a key that is accessed from the file system, not the database. Preferably in a file with 600 permissions owned by someone other than the webserver user and loaded by setuid or the like. This way even if the database is compromised there still isn't enough information to derive the password.
Part 4 is about data structures to store ACLs. There are lots of options for that so have a look around for something which suits you. You might not need a full-blown ACL, instead just having user roles/groups or particular permission flags. This will depend on your application.