如何在 MySQL 中安全地存储用户的密码和盐？

发布于 2024-12-02 05:58:01 字数 1075 浏览 1 评论 0原文

所以，我发现你应该将密码与“盐”一起哈希。（这些文章可以在此处和此处。）

这是代码：

$password = 'fish';

/* should be "unique" for every user? */
$salt= 'ABC09';

$site_key = 'static_site_key';

hash_hmac('sha1', $password . $salt, $site_key);

现在我需要在 MySQL 中保存 $password 和 $salt ，如下所示：

+---------+--------+----------+-------+
| user_id |  name  | password |  salt |
+---------+--------+----------+-------+
|    1    | krysis |  fish**  | ABC09 |
+---------+--------+----------+-------+

** fish 当然会被散列而不是以纯文本形式存储。

我只是想知道这样做是否真的有意义，因为这样黑客或任何人也会知道盐？那么，如果他们破解密码并看到它是 fishABC09，他们就会自动知道密码是 fish 吗？或者他可能“永远”无法破解密码，因为他不知道 secret_key，因为它没有存储在数据库中？

如果我没有任何意义，我很抱歉。我一直使用 sha1 作为密码，今天我发现这些文章讨论了添加 salt。

原文

So, I found out on SO that you're supposed to hash the password together with a "salt". (The articles can be found here and here.)

Here's the code:

$password = 'fish';

/* should be "unique" for every user? */
$salt= 'ABC09';

$site_key = 'static_site_key';

hash_hmac('sha1', $password . $salt, $site_key);

And now I need to save both the $password and $salt in MySQL, like so:

+---------+--------+----------+-------+
| user_id |  name  | password |  salt |
+---------+--------+----------+-------+
|    1    | krysis |  fish**  | ABC09 |
+---------+--------+----------+-------+

** fish will of course be hashed and not stored in plain text.

And I'm just wondering whether or not it actually makes sense to do it this way, because this way a hacker or whoever will also know the salt? So, if they crack the password and the see it's fishABC09 they automatically will know the password is fish? Or might he "never" be able to crack the password because he doesn't know the secret_key, as it isn't stored in the database?

I'm sorry if I'm not making any sense. I just always used sha1 for passwords, and today I found these articles that talked about adding a salt.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

献世佛 2024-12-09 05:58:01

有一些关于正确存储密码的好文章。其中之一例如：存储密码 - 正确完成！

您应该使用不同的盐每个用户，但无需单独存储盐。请参阅另一个线程中的类似讨论

顺便说一句，您可能应该'不要使用 sha1，而是使用 sha256 或 sha512 等更强大的东西（至少可以避免不良宣传）。对此有一个很好的答案：有多不安全加盐 SHA1 与加盐 SHA512 对比

回复收藏 0 原文

眼前雾蒙蒙 2024-12-09 05:58:01

彩虹/字典攻击和加盐密码 - 一种异端方法

密码不应存储在数据库中。不要推出自己的身份验证机制 - 您几乎肯定会出错。使用 Kereberos 来获取有价值的东西，否则我没有什么好的建议。

然而，这个问题已经在我的脑海里萦绕了一段时间（请参阅编辑）
我想提出一个异端观点。

彩虹表之所以如此，是因为使用查找机制（链接）的方式 - 但它们只是字典攻击。预先对数百万字典单词和常用密码进行哈希处理，然后将其用于与被盗的哈希密码进行比较。

这对于使用 md5 散列且无盐的 NT4 密码过程非常有效。但
当在散列之前将盐添加到密码中时，彩虹表就没用了 - 它不是寻找“mypass”的 md5 散列，而是必须预先计算“mypass-random-string_of-letters”

不可能猜测有人会用什么盐使用，因此加盐使彩虹表成为通用的，可以在任何地方使用，以对抗死在水中的任何服务器解决方案。

但是……

这只是一个用例——当然是一个很大的威胁，当然也是一个需要防御的威胁。但
盐有问题。当您想要在下次用户登录时进行身份验证时，您必须保留盐。他们发送明文（通过 ssl！），您将盐和哈希值附加到存储在数据库中的哈希值。但是如果你不保留密码的盐，你就不能这样做，并且错误...无法登录

但是我们不仅要防御人们传递旨在破解 NT4 密码的表。我们应该单独保护我们的用户。

盐为密码添加了两因素防御 - 即使使用哈希，攻击者也需要盐才能有机会破解它。但标准建议只是放弃了这两个因素的防御。也许这是有道理的，但我不相信。

这背后有一些数学知识。通常的建议（RSA 也给出了 - ftp.rsa.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf）是构建一个 64 位 salt，将其存储在
散列密码。通过这种方式，您可以通过使用盐重新散列来重新确认密码，并且反转散列几乎是不可能的。

注意-我在这里可能是错的......

“几乎不可能”的部分来自简单的数学。

假设一个 8 位数字的密码，包含 62 个可能的字符（字母、大写、小写和数字）

，即 62^8 种组合，即略高于 2 亿万亿。

为了暴力破解，通过直接计算哈希（即制作我的盐特定彩虹表），我应该在 62^8/2 之后看到碰撞，假设每秒 100 个哈希，大约需要 1200 万天。是的天。

好的，所以即使将哈希值与密码一起存储，查找哈希值的任务也变得相当不可行。

然而，上面有一些假设。首先，密码是 62^8 范围内的随机选择。实际上，大多数密码要弱得多 - 彩虹表并不是真正基于所有 62^8 种可能性 - 它们是根据字典和多年来发现的真实密码表构建的。

所以搜索空间实际上比 62^8 更小。有多小？这取决于密码的“强度”。

英语约有 250,000 - 750,000 个单词 (http://oxforddictionaries.com/page/93)。让我们以 500,000 为例。然后我们采用可以应用的变体 - 添加数字、添加年份、将元音转换为数字。这给了我们每个单词 3 个可能的新单词，或者 200 万个可能的密码。

以 100 个/秒的速度生成 200 万个哈希值需要 20,000 秒或 5 小时 - 完全在任何笔记本电脑的范围内。

因此，如果有一个特定的用户成为目标（root、admin、spolsky 等），那么立即用密码存储盐使得破解变得可行。

将盐存储在远离密码的地方会增加破解的难度 - 不是以任何数学方式，只是难以获取盐和密码。人们可以设想一个单独的服务器，它只需要明文、用户名和哈希值，然后查找
在用户加入日期上使用的盐，并返回 1/0

因此，简而言之，如果您将盐与密码一起存储并且有人访问密码，则根据密码强度，每个密码都可以在合理的时间内破解。每个用户使用不同的盐可以保护所有其他用户，但如果您要使用特定帐户，那就无关紧要了。如果黑客只需要一个密码，那么将密码与盐一起存储就可以使破解成为可能。在密码表的其他地方保留旋转盐意味着黑客现在需要两次数据窃取才能破解密码，因为如果没有盐，任何攻击都注定要花费数千年的时间。

这都是一种权衡——强迫人们使用 15 位数字的密码意味着他们都会被贴在屏幕上，或者变得“容易记住”，即单词。

此时，您也可以转向 Kerberos 或类似的 - 如果您保护的数据有价值，用户就会理解并尊重它。如果不是，我们为什么要烦恼。

但我仍然建议您不要实现自己的身份验证机制。使用 Kerberos，使用半公共 PKI，不要自己推出。我不知道如何判断我的服务器是否只是将保存我的盐的 RAM 交换到磁盘中，这只是我在滚动自己的身份验证时立即想到的一个错误。

华泰

Rainbow / Dictionary Attacks, and salted passwords - a heretics approach

Passwords should not be stored in your database. Do not roll your own authentication mechanism - you will almost certainly get it wrong. Use Kereberos for valuable stuff, and well I dont have a good suggestion otherwise.

However, this question has been bashing around in my skull for a while (see the edits)
and I would like to put a heretical viewpoint over.

Rainbow tables are so-called because of the way the lookup mechanism (chaining) is used - but they are just dictionary attacks. Millions of dictionary words and common passphrases are hashed up front and then used to compare stolen hashed passwords against.

This worked well for the NT4 password process which used md5 hashes and no salt. But
when a salt is added to a password before hashing, then the rainbow table is useless - instead of looking for the md5 hash of "mypass" it has to precompute "mypass-random-string_of-letters"

Its impossible to guess what salt someone will use, so salting makes rainbow tables as a generic, use anywhere against any server solution dead in the water.

but ...

Thats only one use case - certainly a big threat, certainly one to defend against. But
salts have a problem. You must keep the salt around for when you want to authenticate the next time user logs in. They send their plaintext (over ssl!), you append the salt and hash, comapre to the hash stored in database. But if you dont keep the salt with the password, you cannot do that, and errr... no login

But we are not only defending against people passing around a table desgined to crack NT4 passwrods. We are supposed to protect our users individually.

A salt adds a two factor defence to the passwords - even with the hash an attacker will need the salt to have any chance of cracking it. But the standard advice just gives away that two factor defence. Probably its reasonable, but I am not convinced.

There is a bit of maths behind this. The usual advice (given by RSA as well - ftp.rsa.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf) is build a 64 bit salt, store it with the
hashed password. This way you can re-confirm the password by rehashing with the salt and reversing the hash is next to impossible.

NB - I could be wrong here ...

The "next to impossible" bit comes from simple maths.

Lets assume an 8 digit password, with 62 possible characters (letters, upper lower and numbers)

Thats 62^8 combinations, or a little over 200 million trillion.

To brute force this, by computing the hash directly, (ie making my salt specific rainbow tables) I should see a collision after 62^8/2 and at lets say 100 hashes per second, it will take around 12 million days. Yes days.

OK, so even storing the hash with the password makes the task of finding the hash quite infeasible.

However there are some assumptions in the above. Firstly that the password is a random choice of the range 62^8. In practise most passwords a much much weaker - rainbow tables aren't really based on all 62^8 possibilities - they are built out of dictionaries, and real password tables found over the years.

So the search space, instead of being 62^8 is really smaller. How small ? The depends on the password "strength".

There are about 250,000 - 750,000 words in english language (http://oxforddictionaries.com/page/93). Lets take 500,000 as a simple case. Then lets take variations that can be applied - add a digit, add a year, convert vowels to digits. That gives us say 3 possible new words per word, or 2 million possible passwords.

Generating 2 million hashes at 100 / sec give 20,000 seconds or 5 hours - well within the range of any laptop.

So if there is a specific user being targeted, (root, admin, spolsky etc) then storing a salt with the password immediately makes the cracking feasible.

Storing the salt away from the password increases the difficulty of the crack - not in any mathematical manner, just in difficulty of getting the salt and the password. One could envisage a seperate server that just takes plaintext, username and hash, and looks up the
salt used on that users join date, and returns 1/0

So, in short, if you store the salt with the password and someone accesses the passwords, then depending on password strength, each password is crackable in a reasonable length of time. A different salt per user protects all the other users, but if you are after a specific account, that is irrelevant. If the hacker is only after one password then storing a salt with password makes the crack feasible. Keeping a rotating salt elsewhere from the password table means the hacker now needs two data steals to crack the password, because without the salt any attack is doomed to thousands of years of work.

This is all a trade off - forcing people to use 15 digit passwords means they all get post-it noted to the screen, or become "easy to remember" i.e. words.

At this point you may as well move to Kerberos or similar - if the data you are protecting is valuable the users will understand and rspect it. If not why are we bothering.

But I still recommend you do not implement your own auth mechansim. Use Kerberos, use a semi public PKI, dont roll your own. I have no idea how to tell if my server just swapped the RAM holding my salt into disk and thats only one mistake I can immediately think of in rolling my own authentication.

HTH

回复收藏 0 原文

橪书 2024-12-09 05:58:01

$username = mysql_real_escape_string($username);
$password = mysql_real_escape_string($password);
$time = time();
$query = "
INSERT INTO user (name, unixcreationtime, passhash) 
VALUES ('$username', '$time', SHA2(CONCAT('$time','$password'),512) ";

不要使用 SHA1，它不再安全。
我建议在 MySQL 中进行所有哈希处理，这样您就可以确保哈希结果没有差异。

使用以下方法选择用户：

$query = "SELECT id FROM user 
          WHERE name = '$username' 
            AND passhash = SHA2(CONCAT(creationdate,'$password'),512) ";

$username = mysql_real_escape_string($username);
$password = mysql_real_escape_string($password);
$time = time();
$query = "
INSERT INTO user (name, unixcreationtime, passhash) 
VALUES ('$username', '$time', SHA2(CONCAT('$time','$password'),512) ";

Don't use SHA1, it is no longer secure.
I suggest doing all hashing in MySQL, that way you can be sure there's no difference in the outcome of the hash.

Select a user using:

$query = "SELECT id FROM user 
          WHERE name = '$username' 
            AND passhash = SHA2(CONCAT(creationdate,'$password'),512) ";

回复收藏 0 原文

九命猫 2024-12-09 05:58:01

不会，因为当密码经过哈希处理时，它看起来不像 fishABC09，它看起来像：5f4dcc3b5aa765d61d8327deb882cf99，这是一个 md5 哈希。

为了访问您的系统，即使他们知道哈希值，也无法逆转。我们使用盐是为了增加哈希的复杂性，并防止在彩虹表中进行哈希查找。

例如：执行 Google 搜索为“password”的 md5 哈希值，即： 5f4dcc3b5aa765d61d8327deb882cf99

很多结果，对吧？

现在我要再次创建一个哈希，我仍然会使用“密码”，但我会添加一个 SALT，即“AHG” (*@"。我猜唯一的回应将是这篇文章和一些读过这篇文章的机器人抓取工具:)

cbe57e92ffbb0086320891b9f979156d

应该只是一个很少有结果，或者这篇文章就是这篇文章。

请记住，

请记住这一点...散列是单向，因此即使您获得散列，您也不知道用于创建它的内容

No, because when the password gets hashed it doesn't look like fishABC09, it looks like: 5f4dcc3b5aa765d61d8327deb882cf99 which is an md5 hash.

To gain access to your system, even if they know the hash, it cannot be reversed. We use salts in order to add complexity to our hashes, and to prevent hash lookups in rainbow tables.

For example: Do a Google search for the md5 hash of "password" which is: 5f4dcc3b5aa765d61d8327deb882cf99

A lot of results right?

Now I'm going to create a hash again, I will still use "password", but I will add a SALT which is "AHG(*@". I'm guessing the only response will be for this post and some bot scrapers that have read this post :)

cbe57e92ffbb0086320891b9f979156d

Should be only a few results, or this post which are this post.

Just Remember

Just remember this... hashes are one way, so even if you gain the hash, you do not know what was used to create it

回复收藏 0 原文

如果没结果 2024-12-09 05:58:01

我知道这已经很旧了，但是对于任何偶然发现这篇文章的人来说......

你真正想做的事情是 HMAC。尝试自己这样做会产生问题。例如，您可以部分计算哈希值，这可以减少猜测密码所需的工作量。 HMAC 解决了这些问题。

更好的是 scrypt 或 bcrypt。 HMAC 仍然经常使用旨在快速且易于计算的哈希算法；许多哈希算法甚至都有硬件实现。 bcrypt 的计算量很大，而 scrypt 的内存密集型。两者都让攻击者变得更加困难，但 scrypt 尤其使得构建硬件设备来破解密码变得非常困难。

我真的很喜欢这里的图表： https://github.com/pbhogan /scrypt#为什么你应该使用-scrypt

回复收藏 0 原文

倒带 2024-12-09 05:58:01

这是一个老话题，但其他人也会来到这里，所以我会尝试非常简单地描述它：

如果你执行 hash(password)，你会为每个密码获得相同的哈希值 [hash(password) = hash(password)]。如果两个用户具有相同的密码，您将看到它，因为哈希值相同。某些密码（例如“password”或“12345678”）经常被使用，因此：数据库中的相同哈希值 ->可能是密码“password”或“12345678”（rainbowtable 攻击）。

如果你散列（盐+密码），你不会得到相同密码的相同散列，因为散列（盐1+密码）不是散列（盐2+密码）。

hash(x) 只是一个数学函数，如 f(x)=y。如果你输入相同的 x，你将得到相同的 y。为了安全起见，这个函数必须是“特殊的”。只是不要使用 sha1，因为它不再安全了：D

回复收藏 0 原文