正在使用“盐”吗？ [英] Is using a 'salt' all that good?
问题描述
我并不声称自己是安全专家，但在我看来，添加盐并没有真正发挥巨大作用。
例如，如果用户的密码是john1970，salt是123456，那么这意味着密码是123456john1970，这对攻击者来说更难（如果使用字典攻击，例如彩虹表），攻击者很可能会猜测第一部分是盐。我发现使用非标准方法（比如与一些关键字XORing或对字符代码应用一些简单的数学运算）更加有效。我知道你们大多数人不会同意我的看法，但是这似乎对我更有意义。
您的意见吗？
重复：
不添加盐可以更难猜出密码在前端，它们被添加以确保密码的存储不会泄漏额外的信息。
$ b 实际上salt是为每个密码随机生成的，并且没有任何形式的密码混淆。
<密码永远不会存储在数据库中，只存储哈希（MD5，SHA1，SHA2 *等）。
密码的MD5始终为286755fad04869ca523320acce0dc6a4。如果您只是将MD5存储在密码数据库中，那么您可以查找该字符串并知道密码为'password'。
通过添加' 84824'的总和变成2ca20e59df3a62e5dc4a3a0037372124。但如果你有另一个数据库（或另一个用户使用相同的密码），他们可能会有一个随机盐'8999'，给出：4e7a210a07958cfe24138a644cbb7f84
问题是，如果攻击者要得到密码数据库的副本，密码哈希将是毫无意义的;你甚至无法知道是否有2个或更多的用户使用相同的密码。
编辑：
<比较 - 您应用的数学公式可以颠倒过来。如果你选择一个盐，然后用密码哈希XOR salt，那么攻击者可以撤销XOR操作并获得原始哈希，此时彩虹表非常有用。
如果您认为数学公式无法逆转，那么您可能实际上正在丢失数据，并且您将多个密码映射到相同的最终哈希值。这实际上增加了攻击者找到散列密码的机会，因为任何适当的密码都可以使用。
如果您正在XOR并保留XOR值是安全的，那么这只是一个额外的秘密，需要保留在某个地方，并且泄露有效的秘密会丢失所有的密码（同样由于彩虹表）。用盐没有额外的秘密，操作无法逆转，但可以重复，并且每个密码都需要单独进行攻击。
编辑：当然这是现在彻底相关：我只是以你身份登录
I don't claim to be an expert in security but it seems to me that adding a salt doesn't really make a huge difference.
For example, if the password of the user is john1970 and the salt is 123456, this means that the password is 123456john1970, while this makes things harder for an attacker (if using a dictionary attack, e.g. rainbow tables), the attacker could very possibly guess that the first part is a salt. I find using non-standard methods (like XORing with some key or applying a few simple mathematical operations to the codes of the characters) far more effective. I know most of you won't probably agree with me but but this seems to make more sense to me.
Your opinion?
Duplicate:
Salts aren't added to make guessing a password harder on the front end, they're added to make sure that the storage of the password doesn't leak extra information.
In fact the salt is generated randomly for each password, and stored without any form of obfuscation alongside the password.
Passwords are never stored in a database, only the hash is stored (MD5, SHA1, SHA2* etc).
The MD5 of 'password' is always 286755fad04869ca523320acce0dc6a4. If you just stored the MD5 in the password database, you can just look for that string and know that the password there is 'password'.
By adding a salt of '84824' the sum becomes 2ca20e59df3a62e5dc4a3a0037372124. But if you got another database (or another user uses the same password), they may have a random salt of '8999', giving: 4e7a210a07958cfe24138a644cbb7f84
The point is that if an attacker were to get a copy of the password database, the password hashes would be meaningless; you wouldn't even be able to tell if 2 or more users were using the same password.
Edit:
In comparison - the mathematical formula you apply can be reversed. If you choose a salt, then XOR the salt with the password hash, then the attacker can just undo the XOR operation and get the original hash, at which point rainbow tables are extremely useful.
If you think the mathematical formula can't be reversed, there's a chance that you're actually losing data, and that you're mapping multiple passwords to the same final hash. This actually multiplies the chance that the attacker will find a password for the hash, since any of the appropriate passwords will work.
If you're XOR'ing and keeping the XOR value secure, then it's just an extra secret that needs to be kept somewhere, and divulging that secret effectively loses all your passwords (again due to rainbow tables). With salts there are no additional secrets, the operation cannot be reversed, but can be repeated, and each password needs to be attacked individually.
Edit: Of course this is now thoroughly relevant: I just logged in as you
这篇关于正在使用“盐”吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
