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

问题描述

可能存在重复：

需要一些帮助了解密码盐

更新：请注意我不是问什么是盐，什么是彩虹桌，字典攻击是什么，或盐的目的是什么。我在查询：如果你知道用户salt和hash，是不是很容易计算他们的密码？

我理解这个过程，并实现它自己在我的一些项目中。

pre code $ s随机盐
storedPassword = sha1（密码+ s）

在您存储的数据库中：

  username | hashed_pa​​ssword | salt 
  

每次执行salting时，都会在密码末尾添加salt，或者开始：
$ b $

  hashed_Password = sha1（s +密码）
 hashed_Password = sha1（密码+ s）
  

因此，一位值得他加盐的黑客的字典攻击（哈哈）只会将每个关键字与存储的盐在上面列出的常见组合中。

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

我只能想到要做一个秘密混合算法，和密码，或者将其他用户字段添加到散列过程中，这意味着黑客必须有权访问数据库和代码，以便将它们绑定到字典式攻击以证明富有成效。 （更新，正如在评论中指出的那样，最好假设黑客可以访问你的所有信息，所以这可能不是最好的）。

让我举个例子我建议黑客如何使用密码和哈希列表破解用户数据库：

来自我们被黑客入侵的数据库的数据：

  RawPassword（未保存）|散列|盐
 --------------------------------------------- ----------- 
 letmein WEFLS ... WEFOJFOFO ... 
  

常用密码字典：

 常用密码
 ------------- -  
 letmein 
 12345 
 ... 
  

对于每个用户记录，循环常用密码并对它们进行哈希处理：

 为hacked_DB中的每个用户
 
 salt = users_salt 
 hashed_pw = users_hashed_pa​​ssword 
 
 for each common_password 
 
 testhash = sha1（common_password + salt）
如果testhash = hashed_pw then 
 //匹配！用户密码= common_password 
 //让我们现在访问网页并登录。 
 end if 
 
 next 
 
 next 
  

假设有10,000个通用密码和10,000个用户记录，我们需要计算100,000,000个散列来发现尽可能多的用户尽可能的密码。这可能需要几个小时，但这不是一个真正的问题。

破解理论更新

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

此网站声称能够使用GPU每秒计算2,300,000,000个SHA1哈希值。 （在现实世界中情况可能会变慢，但现在我们将使用该引用的数字）。

lockquote
<（p（（95 ^ 4）给定全范围的95个可打印的ASCII字符，并带有一个字母a，b，b，b，b，b，b，b，b，b，b，最大长度为4个字符，除以计算速率（可变），除以2（假设发现密码的平均时间平均需要50％的排列），对于10,000个用户，需要177秒来计算所有用户密码其中长度<= 4。

现在让我们来调整一下。

（p（（（36 ^ 7）/ 1000000000）/ 2）* 10000 = 2天

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

这是我重要的是要认识到这是一个线性蛮力攻击，所有计算都是彼此独立的，因此对于多个系统来说这是一个完美的任务。 （IE容易设置两台计算机从不同的端运行攻击，执行时间仅为执行时间的一半）。

假设递归哈希密码的次数为1,000次计算量更大：

lockquote
（（（36 ^ 7）/ 1 000 000 000）/ 2）* 1000
seconds = 10.8839117小时

这表示最大长度为7个字母数字字符，其速度低于执行引用数字时的一半速度>一个用户。

递归哈希1000次有效地阻止了一次全面攻击，但针对用户数据的攻击目前依然存在。

$ b $是的，你只需要3天sha1（salt |密码）。这就是为什么好的密码存储算法使用1000次迭代散列：您需要8年。

Possible Duplicate:
Need some help understanding password salt

Update: Please note I am not asking what a salt is, what a rainbow table is, what a dictionary attack is, or what the purpose of a salt is. I am querying: If you know the users salt and hash, isn't it quite easy to calculate their password?

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

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

In the database you store:

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 dictionary:

   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.

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.

Update on Cracking Theory

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.

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 seconds

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 days

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.

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).

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 seconds = 10.8839117 hours

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

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

解决方案

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屋！