从HASH中获取原始值
前几天我在我们的企业系统上发现了一张表——dba_users (oracle)。
我能够在此表中找到每个员工的哈希密码以及他们的用户名。
据我所知（通过谷歌搜索），用户名+密码被连接起来，然后进行哈希处理。
问题：知道“盐”（我自己的用户名）、“原始值”（我自己的密码）以及哈希值……能够算出哈希值是否存在危险？
另外——谷歌搜索 oracle 10g 哈希——似乎有些人认为他们已经弄清楚了哈希算法。我读过有关“彩虹表”和“离线字典攻击”的内容...最后，我在 google 上搜索了 oracle 11g，该版本的功能之一是它们将哈希密码隐藏在 dba_users 中，以便最终用户可以没看到它。
不管怎样，我很困惑为什么我（即最终用户）可以访问这个表，以及为什么 DBA 似乎不太担心它。
I came across a table the other day on our enterprise system -- dba_users (oracle).
I was able to find a hashed password in this table for each employee, and also their username.
As far as I know (from googling) the username + password is concatenated, then hashed.
Question: knowing the "salt" (my own username), the "original value" (my own password), and also the hashed value...is there a danger here of being able to figure-out the hash?
Also -- googling oracle 10g hash -- seems like some folks think they've figured the hash algorythm out. And I've read about "rainbow tables" and "offline dictionary attacks"... And finally, I've googled oracle 11g, and one of the features in that version is they hide the hashed password in dba_users so end-users can't see it.
Anyway, I'm scratching my head over why I (i.e., end-users) have access to this table, and why the DBA dosen't seem too worried about it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对密码进行哈希处理然后将哈希值存储到数据库的全部目的是，如果这样做，您将不必担心谁可以看到表中的密码。
强调一下：如果没有原始密码，存储在数据库中的（正确计算的）密码哈希值是完全无用的。
据我所知，对于像 md5 这样的算法，没有办法从哈希值逆向工程原始密码。这就是为什么当您单击“我忘记”链接时，现在大多数服务不会向您发送密码 - 相反，他们会提供设置新密码（只要您提供旧密码并且服务会比较哈希值）。
The whole point of hashing the password and then storing the hash to database is that if you do so you won't have to worry about who can see the password in the table.
To emphasize: a (properly calculated) hash value of a password which is stored in database is completely useless without the original.
As far as I know, for algorithms like md5, there isn't a way to reverse engineer the original password from hash whatsoever. That's why most services nowadays don't send you your password when you click 'I forgot' link - instead they offer to set a new one (as soon as you provide the old password and the service compares hashes).
通过将每个散列密码与用户名连接（即加盐）来详细说明@Goran Jovic 所说的内容。提供此功能没有任何危险。要理解这一点，您必须了解彩虹表的工作原理。使用彩虹表破解一系列密码的方法是将一系列预先计算的哈希值从密码加载到内存中。然后，搜索与未知密码相关的哈希表，看看是否可以在彩虹表中找到匹配项（您知道与特定哈希对应的密码）。然而，通过使用唯一标识符（即用户名）对哈希值加盐，您就可以击败这种攻击，因为即使是已经看到的密码也会根据与其关联的用户而进行不同的哈希值。因此，现在彩虹表不必处理数百万种可能的不同密码组合，而是必须包含每个可能的密码加上每个可能的用户名的哈希值。其结果空间太大而无法搜索，除非计算技术出现质的飞跃，否则无法使用暴力策略来击败。
Elaborating on what @Goran Jovic said, by concatenating (ie salting) each hashed password with the username.There is no danger in making this available. To make sense of this, you have to understand how a rainbow table work. The way a series of passwords is cracked with a rainbow table is by loading up a precomputed series of hashes from passwords into memory. Then, searching through the table of hashes associated unknown passwords to see if you can find a match in the rainbow table (of which you know the password corresponding with a specific hash). By salting the hashes with a unique identifier (ie a username), however, you defeat this attack because even a password that's already been seen will hash differently depending n the user associated with it. Therefore now, instead of a rainbow table having to handle the millions of different password combinations possible, it must now contain a hash of every possible password plus every possible username. The results space of this is simply too large to search and unless there was a quantum leap in computing technology impossible to beat using a bruteforce tactic.