如何为用于保护密码的哈希函数选择盐? [英] How to choose a salt for a hash function meant to protect passwords?

问题描述

我是一个(几乎完整的)初学者，这是我第一次尝试加密-实际上这可能是我第一次使用这个词.

这是我的问题:对于非银行/军事或什至商业的Web应用程序，为用于密码的哈希函数选择盐的正确方法是什么?

我可以轻松地为每个新用户生成一个伪随机盐，并在应用哈希函数之前将该盐附加到他们的pw中.但是我仍然需要存储盐，大概是任何访问哈希密码的人都可以得到盐.

盐的好处仅仅是使pw更加随机"，从而击败了基于字典的标准彩虹表吗?

以下任何一项都可以吗?实用想法:

1. 将盐存储在单独的数据库中-也许是单独的系统，绝对是不同的主机，名称，密码等.
2. 根据用户名(或名字+姓氏或注册日期)的哈希值生成盐，大概是使用其他哈希函数吗?则盐本身将不会存储在db中-仅用于计算它的数据会...
3. 在数据库中存储一个以非显而易见的方式将散列的pw和盐连接起来的值(例如，salt是10个随机密钥，并且将它们注入到散列的pw中，字母数字1和2、4和4之间). 5、8& 9等).

作为附带的问题，在升级网站软件时更改盐渍哈希算法有多容易?现在感觉像噩梦.

解决方案

1. 使密码检查更加困难-不推荐.
2. 最好只是生成一个随机数(64位可能就足够了.)
3. 请参阅(部分) SO 1191112 .盐不必是秘密的；只是必须有所不同.

要回答您的副问题:还要随数据存储一个算法ID(可能是一个简单的数字，可能是一个名称字符串).升级时，您使用新的首选算法对新密码进行哈希处理，但是保留了旧算法，直到每个人都更改了密码并且使用旧算法没有存储的密码为止.同样，这不必是秘密的-它只允许您适应世界的变化.显然，如果旧算法突然暴露为一文不值，您会考虑使用增量方法是否可以.但是除非发生类似这样的戏剧性变化，否则逐步采用新机制的效果会很好.尽量不要经常更改算法，以便一次拥有三个或三个以上的算法-尽管没有技术上的理由可以使该方案无法对其进行管理.还应尝试设计数据库，以便散列大小可以增加而不会引起限制(因此，可以将扩展空间从64字节扩展到128字节，或者从128扩展到256，或者...).

I'm a (near complete) beginner, and this is my first foray into encryption - in fact this is probably the first time I use the word.

Here is my question: For a non banking / military, or even commercial, web app, what is the right way to choose a salt for a hash function used for passwords?

I can easily generate a pseudo random salt for each new user, and append that salt to their pw before applying the hash function. But I still need to store the salt so presumably anyone who gets access to the hashed passwords also gets the salts.

Is the benefit of the salt simply to make the pw "more random", and therefore defeat the standard dictionary-based rainbow tables?

Would any of the following be good & practical ideas:

1. Store the salt in a separate db - maybe a separate system, definitely a different host, name, pw, etc.
2. Generate the salt based on a hash of a user name (or first+last name, or sign up date), presumably using a different hash function? Then the salt itself would not be stored in the db - only the data used to compute it would...
3. Store in the db a value which concatenates the hashed pw and the salt, in a non obvious manner (e.g., the salt is 10 random keys, and they are injected inside the hashed pw between letter numbers 1&2, 4&5, 8&9, etc).

As a side question, how easy is it to change a salted hash algorithm when upgrading the software of the website? It feels nightmarish right now.

解决方案

1. Makes checking the passwords more difficult - not recommended.
2. Better just to generate a random number (64-bit is likely enough).
3. See (in part) SO 1191112. The salt doesn't have to be secret; it just has to be different.

To answer your side question: also stash an algorithm ID (possibly a simple number, possibly a name string) along with the data. As you upgrade, you hash new passwords using the new, preferred algorithm, but you retain the old algorithm until everyone has changed their password and there are no stored passwords using the old algorithm. Again, this does not have to be secret - it just allows you to adapt to changes in the world. Clearly, if the old algorithm is suddenly exposed as worthless, you think about whether it is OK to use the incremental approach. But unless something dramatic like that happens, phasing in the new mechanism works pretty well. Try not to change your algorithm so often that you have three or more on the go at once - though there's no technical reason that the scheme cannot manage it. Also try to design your database so that the hash sizes can grow without causing ructions (so allow room for expansion from 64 to 128 bytes, or from 128 to 256, or ...).

这篇关于如何为用于保护密码的哈希函数选择盐?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！