Do you guys think salting password with the first 8 bit of the password itself will have same result as using stored salt to hash password?
[Clarification] I am not storing salt but creating from the password itself during authentication.
Followup question, instead of using first 8 bit how about the first (length of the password mod (Prime number)) of bits as a salt? would not this be securer than normal password hashing?
This scheme looks clever, but it isn't.
Salts are usually stored in cleartext. And they serve one purpose - to restrict the usability of precomputed hash tables. There is also the side-effect that no two hashes computed for two different user accounts with the same password will be the same.
By storing a portion of the password as a salt, you are decreasing the security posture of the application, and also complicating matters. The below points assume storage of the salt:
Cryptographic properties of a salt
This is based on Paul's answer and the comments interspersed on this page. This section does not assume storage of the salt, and is rather a note on how salts must be chosen. Any data used as a salt to a password, must satisfy certain cryptographic properties. The most important one is that
A salt must be unique across the passwords stored in the system.
If the salt is not unique, then one loses the ability to create unique hashes for every password managed by the system, leading to the possibility that a dump of hashes might reveal passwords that are used across accounts or passwords present in dictionaries.
It cannot be guaranteed that the scheme in question has this property. In fact it is easy to assume that the property is bound to be absent in a system with more than 2^8 = 256 users, rendering the scheme quite useless.
Also, if one is under the impression that this scheme can reasonably protect against pre-computed hashes then that assumption is moot. It assumes that an attacker does not have resources at his disposal to compute hashes to compromise all the accounts in a reasonable timeframe. Using a salt with the cryptographic property of being unique would have certainly slowed down the attacker by a large factor, as a computed hash would be valid only for one salt and not for the others (i.e. hashes for any password in a dictionary must be recomputed for every user). If the current scheme were to be employed, an attacker can restrict himself to computing only 1 hash per password in a dictionary, making it no different from not using a salt, thus making it pointless to have a salt in the first place.
This would lead to another property of a cryptographic salt:
A salt must enhance the resistance of the system against bruteforce attacks and the like.
By using a salt derived from a password, one loses this property, for a hash of every password in a dictionary can be computed in more or less the same amount of time, with or without the salt.
It it to this effect that most systems are engineered to generate the salt of sufficient length using a secure PRNG. One of the comments stated that using a "service name" + "user name" combination is enough. I would say that it is a good thing to start of with. The service name typically acts as a pepper (especially when it is not stored), so that hashes themselves cannot be copied and used across services using the same hashing scheme. The username is decent enough to use as a salt, except in scenarios where the username is public (the root account in *nix, or Administrator in Windows, for example). If your usernames will be public and consistent across several deployments, then using n bits of randomness ought to be the way to go. This is an extension of the second property, in that any choice of a salt must consider resistance to bruteforce attacks across all deployments.
The followup question states -
Instead of using first 8 bit how about the first (length of the password mod (Prime number)) of bits as a salt? would not this be securer than normal password hashing?
No, the salt is not guaranteed to be unique across user accounts. (See the first crytographic property).
Using part of the password as the salt is no better than using no salt at all -- it just has the effect of slightly redefining your hash function.
The whole point of salt is to have some input to the password hash independent of the password itself that an adversary attempting a dictionary attack can't predict in advance. n bits of salt forces him to create 2^n hashes in his dictionary for each password, one for each possible salt value. He doesn't know which salt values are actually in use until he steals the password file.
However, if the salt is just some function of the password, then the attacker knows exactly what value of salt will be used for any particular password, so he only needs one hash per password in his dictionary, the same as the case where there is no salt at all, and he can build this dictionary in advance.
Another way of looking at it: salting prevents two accounts that happen to have the same password from having the same password hash. (Well, there's a 2^-n chance of randomly picking the same salt for each, but you know what I mean.) If the salt is computed from the password itself instead of being randomly generated, then two accounts with the same password will always have the same password hash.
If the salt is computed from the password itself instead of being randomly generated, then two accounts with the same password will always have the same password hash. If you are not storing the salt and if you are deriving it from the password, the hashes generated for two users will be the same if they have the same password (which is the scenario that salts are meant to prevent).
Commented
Jul 12, 2011 at 7:38