加密、哈希和密码问题，完全是菜鸟?

如果有人可以访问您的数据库/数据，那么他们仍然需要弄清楚您的散列算法，并且您的数据仍然会有些安全，这取决于您的算法?他们所拥有的只是哈希和盐.

If someone has access to your database/data, then they would still have to figure out your hashing algorithm and your data would still be somewhat secure, depending on your algorithm? All they would have is the hash and the salt.

如果有人可以访问您的数据库/数据和您的源代码，那么似乎无论您做什么，您的哈希算法都可以进行逆向工程，您唯一能做的就是如何您的算法复杂且耗时?

If someone has access to your database/data and your source code, then it seems like no matter what your do, your hashing algorithm can be reversed engineered, the only thing you would have on your side would be how complex and time consuming your algorithm is?

似乎最薄弱的环节是:您自己的系统有多安全以及谁可以访问它?

It seems like the weakest link is: how secure your own systems are and who has access to it?

Lasse V. Karlsen ...提出了一个很好的观点，如果您的数据被泄露，那么游戏就结束了...我的后续问题是:这些哈希试图防止哪些类型的攻击?我读过彩虹表和字典攻击(蛮力)，但这些攻击是如何管理的?

Lasse V. Karlsen ... brings up a good point, if your data is compromised then game over ... my follow up question is: what types of attacks are these hashes trying to protect against? I've read about rainbow table and dictionary attacks (brute force), but how are these attacks administered?

您的问题是关于使用密码作为身份验证机制以及如何使用哈希将这些密码安全地存储在数据库中.正如您可能已经知道的那样，目标是能够在不存储这些密码的情况下验证密码，我在数据库中使用明文.在这种情况下，让我试着回答你的每一个问题:

You question is about using passwords as an authentication mechanism and how to securely store these passwords in a database using a hash. As you probably already know the goal is to be able to verify passwords without storing these passwords i clear text in the database. In this context let me try to answer each of your questions:

如果有人可以访问您的数据库/数据，那么他们仍然需要弄清楚您的散列算法并且您的数据仍然会有些安全，这取决于您的算法?他们所拥有的只是哈希和盐.

If someone has access to your database/data, then they would still have to figure out your hashing algorithm and your data would still be somewhat secure, depending on your algorithm? All they would have is the hash and the salt.

散列密码的基本思想是攻击者知道散列算法并且可以访问散列和盐.通过为每个密码选择不同的加密强散列函数和合适的盐值，猜测密码所需的计算量非常高，以至于成本超过了攻击者从猜测密码中获得的可能收益.所以回答你的问题，隐藏哈希函数并不能提高安全性.

The basic idea of hashing passwords is that the attacker has knowledge of the hashing algorithm and has access to both the hash and the salt. By selecting a cryptographic strong hash function and a suitable salt value that is different for each password the computational effort required to guess the password is so high that the cost exceeds the possible gain the attacker can get from guessing the password. So to answer your question, hiding the hash function does not improve the security.

如果有人可以访问您的数据库/数据和您的源代码，那么似乎无论您做什么，您的哈希算法都可以进行逆向工程，您唯一需要的就是复杂性和时间消耗你的算法是什么?

If someone has access to your database/data and your source code, then it seems like no matter what your do, your hashing algorithm can be reversed engineered, the only thing you would have on your side would be how complex and time consuming your algorithm is?

您应该始终使用众所周知的(并且适当强大的)散列算法，并且对该算法进行逆向工程没有意义，因为您的代码中没有任何隐藏内容.如果您的意思不是逆向工程师，而是实际上逆向，那么，是的，密码受到反向哈希函数(或猜测与哈希匹配的密码)的复杂性保护价值).好的哈希函数让这变得非常困难.

You should always use a well-known (and suitably strong) hashing algorithm, and reverse engineering this algorithm is not meaningful as there is nothing hidden in your code. If you didn't mean reverse engineer but actually reverse then, yes, the passwords are protected by the complexity of reversing the hash function (or guessing a password that matches a hash value). Good hash functions makes this very hard.

似乎最薄弱的环节是:您自己的系统有多安全以及谁可以访问它?

It seems like the weakest link is: how secure your own systems are and who has access to it?

一般来说这是对的，但在通过将密码存储为哈希来保护密码时，您仍然应该假设攻击者可以完全访问哈希，并通过选择适当的哈希函数和使用盐来相应地设计您的系统.

In general this is true, but when it comes to securing passwords by storing them as hashes you should still assume that the attacker has full access to the hashes and design your system accordingly by choosing an appropriate hash function and using salts.

这些哈希试图防止哪些类型的攻击?我读过彩虹表和字典攻击(蛮力)，但是这些攻击是如何管理的?

What types of attacks are these hashes trying to protect against? I've read about rainbow table and dictionary attacks (brute force), but how are these attacks administered?

密码散列可防止的基本攻击是攻击者可以访问您的数据库.明文密码无法从数据库中读取，密码受保护.

The basic attack that password hashing protects against is when the attacker gets access to your database. The clear text password cannot be read from the database and the password is protected.

更老练的攻击者可以生成可能的密码列表，并使用与您相同的算法计算哈希值.然后，他可以将计算出的散列与存储的散列进行比较，如果找到匹配项，他就有一个有效的密码.这是一种蛮力攻击，通常假定攻击者对您的数据库具有离线"访问权限.通过要求用户使用长而复杂的密码，暴力破解"密码所需的工作量显着增加.

A more sophisticated attacker can generate a list of possible passwords and compute the hash using the same algorithm as you. He can then compare the computed hash to the stored hash and if he finds a match he has a valid password. This is a brute force attack and it is generally assumed that the attacker has "offline" access to your database. By requiring the users to use long and complex passwords the effort required to "brute force" a password is significantly increased.

当攻击者想要攻击的不是一个密码，而是数据库中的所有密码时，可以使用所谓的哈希链预先计算并进一步改进数据库中的密码和哈希值对的大表.彩虹表是这个想法的一个应用，可以用来同时暴力破解多个密码，而不会显着增加工作量.但是，如果使用唯一的 salt 来计算每个密码的哈希值，那么预先计算的表就会变得毫无用处，因为每个 salt 的值都不相同，并且无法重复使用.

When the attacker wants to attack not one password, but all the passwords in the database a large table of passwords and hash value pairs can be precomputed and further improved by using what is called hash chains. Rainbow tables is an application of this idea and can be used to brute force many passwords simultaneously without increasing the effort significantly. However, if a unique salt is used to compute the hash for each password a precomputed table becomes useless as it is different for each salt and cannot be reused.

总而言之:隐匿安全并不是保护敏感信息的好策略，而现代密码学允许您保护信息而不必诉诸隐匿.

To sum it up: Security by obscurity is not a good strategy for protecting sensitive information and modern cryptography allows you to secure information without having to resort to obscurity.