为什么盐使字典攻击“不可能"? [英] Why do salts make dictionary attacks 'impossible'?

问题描述

更新:请注意，我不是在问什么是盐，什么是彩虹表，什么是字典攻击，或者盐的目的是什么.我在问:如果你知道用户salt和hash，是不是很容易算出他们的密码?

我了解这个过程，并在我的一些项目中自己实施.

I understand the process, and implement it myself in some of my projects.

s =  random salt
storedPassword = sha1(password + s)

在您存储的数据库中:

username | hashed_password | salt

我见过的每个加盐实现都会在密码的末尾或开头添加盐:

Every implementation of salting I have seen adds the salt either at the end of the password, or beginning:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

因此，来自值得他的盐(哈哈)的黑客的字典攻击将简单地针对上面列出的常见组合中存储的盐运行每个关键字.

Therfore, a dictionary attack from a hacker who is worth his salt (ha ha) would simply run each keyword against the stored salts in the common combinations listed above.

当然，上面描述的实现只是为黑客添加了另一个步骤，而没有真正解决潜在的问题?有什么替代方法可以解决这个问题，还是我误解了这个问题?

Surely the implementation described above simply adds another step for the hacker, without actually solving the underlying issue? What alternatives are there to step around this issue, or am I misunderstanding the problem?

我唯一能想到的就是有一个秘密混合算法，以随机模式将盐和密码结合在一起，或者将其他用户字段添加到散列过程中，这意味着黑客必须能够访问数据库并且代码将它们绑在字典攻击中以证明卓有成效.(更新，正如评论中指出的那样，最好假设黑客可以访问您的所有信息，因此这可能不是最好的).

The only thing I can think to do is have a secret blending algorithm that laces the salt and password together in a random pattern, or adds other user fields to the hashing process meaning the hacker would have to have access to the database AND code to lace them for a dictionary attack to prove fruitful. (Update, as pointed out in comments it's best to assume the hacker has access to all your information so this probably isn't best).

让我举一个例子，说明我建议黑客如何使用密码和哈希列表来入侵用户数据库:

Let me give an example of how I propose a hacker would hack a user database with a list of passwords and hashes:

来自我们被黑数据库的数据:

Data from our hacked database:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

常用密码字典:

   Common Password
   --------------
   letmein
   12345
   ...

对于每个用户记录，循环常用密码并对其进行散列:

For each user record, loop the common passwords and hash them:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

我希望这能更好地说明我的观点.

I hope this illustrates my point a lot better.

给定 10,000 个常用密码和 10,000 条用户记录，我们需要计算 100,000,000 个哈希值才能发现尽可能多的用户密码.这可能需要几个小时，但这不是真正的问题.

Given 10,000 common passwords, and 10,000 user records, we would need to calculate 100,000,000 hashes to discover as many user passwords as possible. It might take a few hours, but it's not really an issue.

裂纹理论更新

我们假设我们是一个损坏的虚拟主机，它可以访问 SHA1 哈希和盐的数据库，以及您的算法来混合它们.该数据库有 10,000 条用户记录.

We will assume we are a corrupt webhost, that has access to a database of SHA1 hashes and salts, along with your algorithm to blend them. The database has 10,000 user records.

该网站声称能够使用 GPU 每秒计算 2,300,000,000 个 SHA1 哈希值.(在现实世界中可能会更慢，但现在我们将使用引用的数字).

This site claims to be able to calculate 2,300,000,000 SHA1 hashes per second using the GPU. (In real world situation probably will be slower, but for now we will use that quoted figure).

(((95^4)/2300000000)/2)*10000 = 177秒

(((95^4)/2300000000)/2)*10000 = 177 seconds

给定全范围的 95 个可打印 ASCII 字符，最大长度为 4 个字符，除以计算速率(变量)，再除以 2(假设发现密码的平均时间将平均需要 50% 的排列)) 对于 10,000 个用户，计算长度小于等于 4 的所有用户密码需要 177 秒.

Given a full range of 95 printable ASCII characters, with a maximum length of 4 characters, divided by the rate of calculation (variable), divided by 2 (assuming the average time to discover password will on average require 50% of permutations) for 10,000 users it would take 177 seconds to work out all users passwords where the length is <= 4.

让我们稍微调整一下以使其更逼真.

Let's adjust it a bit for realism.

(((36^7)/1000000000)/2)*10000 = 2 天

(((36^7)/1000000000)/2)*10000 = 2 days

假设不区分大小写，密码长度 <= 7，只有字母数字字符，解决 10,000 条用户记录需要 4 天时间，我将算法速度减半以反映开销和非理想情况.

Assuming non case sensitivity, with a password length <= 7, only alphanumeric chars, it would take 4 days to solve for 10,000 user records, and I've halved the speed of the algorithm to reflect overhead and non ideal circumstance.

重要的是要认识到这是一种线性蛮力攻击，所有计算都是相互独立的，因此对于多个系统来说，这是一项完美的任务.(IE很容易设置2台计算机从不同的端运行攻击，执行时间减半).

It is important to recognise that this is a linear brute force attack, all calculations are independant of one another, therfore it's a perfect task for multiple systems to solve. (IE easy to set up 2 computers running attack from different ends that would half the exectution time).

假设将密码递归散列 1,000 次以增加此任务的计算成本:

Given the case of recursively hashing a password 1,000 times to make this task more computationally expensive:

(((36^7)/1 000 000 000)/2) * 1000秒 = 10.8839117 小时

(((36^7) / 1 000 000 000) / 2) * 1000 seconds = 10.8839117 hours

这表示最大长度为 7 个字母数字字符，以不到 一个用户引用数字的一半速度执行.

This represents a maximum length of 7 alpha-numeric characters, at a less than half speed execution from quoted figure for one user.

递归散列 1,000 次有效地阻止了全面攻击，但对用户数据的针对性攻击仍然容易受到攻击.

Recursively hashing 1,000 times effectively blocks a blanket attack, but targetted attacks on user data are still vulnerable.

推荐答案

是的，sha1(salt | password) 只需要 3 天.这就是为什么好的密码存储算法使用 1000 次迭代哈希:你需要 8 年.

Yes, you need just 3 days for sha1(salt | password). That's why good password storage algorithms use 1000-iteration hashing: you will need 8 years.

这篇关于为什么盐使字典攻击“不可能"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！