Is using a 'salt' all that good?

2019-06-09 12:44发布

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:

13条回答
淡お忘
2楼-- · 2019-06-09 12:46

If your salt is big enough, it's not practical to create said rainbow table.

http://en.wikipedia.org/wiki/Salt_(cryptography)

It's also about having mutiple factors being used to encrypt your passwords. While someone might steal your database, they might leave out the salt, and thus be SOL.

查看更多
戒情不戒烟
3楼-- · 2019-06-09 12:50

A salt is used in conjunction with a cryptographic hash, not merely tacked on the front of the password. You don't store the salted password or the password, but rather the hash of the salted password. The purpose of a salt is to protect users from "bad" password choices, not obscure the password. You never use just a salt.

To clarify: A salt will not protect against a dictionary attack. It can protect against a rainbow table style attack, where a large table of hashed and a corresponding input text is generated. Good passwords protect against guesses (dictionary attacks), salts help protect against someone getting a hold of your hashed passwords, by making it expensive to use precomputed tables. When I said "bad" I meant passwords that were likely to be in the extant tables.

查看更多
仙女界的扛把子
4楼-- · 2019-06-09 12:52

Security axiom: never ever store plain-text passwords in the database.

With this in mind, salt suddenly makes a big difference: because of this salt, the attacker’s pre-calculated hashes (the aforementioned rainbow tables) are of no value.

查看更多
Luminary・发光体
5楼-- · 2019-06-09 12:53

What you're saying doesn't make any sense. Let's go with a simplified example to demonstrate. Assume you're using MD5, and the attacker has a table. The table includes:

john1970->D3 88 99 BC 0C B5 DC 0E D1 7F BB F7 EB F4 EA B2

If they then steal your unsalted database and see a hash D3...B2, they'll know (ignoring collisions) the password was john1970, and they can then use that password on your site and possibly others. If however, you use the salt 123456 (obviously, a random one would be better), they will see a hash:

2A CA 76 59 03 23 35 61 E0 20 49 11 8F FE F3 0E

instead. Even if they are able to compromise the salt when they get the hashes (you should try to prevent this by storing them separately), they will be left with:

md5(x+123456) = 2A...0E

and no way to easily determine x. Salts are a very powerful technique, and should be used whenever possible. On the other hand, what you call "non-standard methods" appear to be half-cocked attempts at inventing your own unproven hashing algorithm. Forget that.

查看更多
时光不老,我们不散
6楼-- · 2019-06-09 12:55

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

查看更多
该账号已被封号
7楼-- · 2019-06-09 12:57

The purpose of the salt is not just to obfuscate the password, but to add to its length. It doesn't help much that the hacker guesses that there is a salt, if he doesn't know what it is. If the salt doubles the length of the password, that raises the number of possible words to the second power. Your XOR method doesn't do that.

查看更多
登录 后发表回答