Return to Answer

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. The apparent loss in entropy has already been pointed out (see above).

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.

By storing a portion of the password as a salt, you are decreasing the security posture of the application, and also complicating matters:

• I would consider that the entropy associated with the password is reduced by a minimum value of the entropy associated with the 8 bits; in the Shannon model of calculating entropy of user selected passwords from a 94 character alphabet, this around 4 bits of entropy. The reduction in entropy is due to the model in use - most passwords are not a sequence of random bits, especially if they are chosen from natural languages. Concatenating n-bits from the password to itself to compute a hash will quite obviously make the contents of the password even less random, thus reducing entropy.
• Using the first 8 bits of the password as the salt is in itself a poor decision, compared to using the last 8 bits, not that the latter is a good decision. It so happens that under the Shannon model for computing entropy of a password, the entropy per bit reduces as the length of the password increases. If you are using the first n bits as the salt, then you are weakening the password further, as the Shannon model works on the premise that "if the first n bit is known, then how well can anyone guess the other following bits".
• Now that you've stored the password fragment in cleartext, you will need to encrypt it. That sounds easy, except that keys have to associated with a management lifecycle where you need to issue them, protect them, and discard them after a particular period; getting of this right is certainly not as easy as using a secure PRNG to generate the salt and storing this random sequence of bits in the clear. This is irrelevant if one is not storing the salt.

This is based on Paul's answer and the comments interspersed on this page. Any data used as a salt to a password, must satisfy certain cryptographic properties. The most important one is that

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.

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:

• I would consider that the entropy associated with the password is reduced by a minimum value of the entropy associated with the 8 bits; in the Shannon model of calculating entropy of user selected passwords from a 94 character alphabet, this around 4 bits of entropy. The reduction in entropy is due to the model in use - most passwords are not a sequence of random bits, especially if they are chosen from natural languages. Concatenating n-bits from the password to itself to compute a hash will quite obviously make the contents of the password even less random, thus reducing entropy.
• Using the first 8 bits of the password as the salt is in itself a poor decision, compared to using the last 8 bits, not that the latter is a good decision. It so happens that under the Shannon model for computing entropy of a password, the entropy per bit reduces as the length of the password increases. If you are using the first n bits as the salt, then you are weakening the password further, as the Shannon model works on the premise that "if the first n bit is known, then how well can anyone guess the other following bits".
• Now that you've stored the password fragment in cleartext, you will need to encrypt it. That sounds easy, except that keys have to associated with a management lifecycle where you need to issue them, protect them, and discard them after a particular period; getting of this right is certainly not as easy as using a secure PRNG to generate the salt and storing this random sequence of bits in the clear.

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

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).

• By using the password fragment as a salt, you would store a portion of the password in cleartext. If it is 8 bits, I would consider that the entropy associated with the password is reduced by a minimum value of the entropy associated with the 8 bits; in the Shannon model of calculating entropy of user selected passwords from a 94 character alphabet, this around 4 bits of entropy. In short, you've made an attacker's work easier. Note that entropy decreases by a minimum value; the actual decrease could be much higher. For instance, if the attacker knows that the user uses a repetition of the first 8 bits as the password, the effective entropy is 0; by knowing the first character, the attacker now knows all the characters in the password.
• Using the first 8 bits of the password as the salt is in itself a poor decision, compared to using the last 8 bits, not that the latter is a good decision. It so happens that under the Shannon model for computing entropy of a password, the entropy per bit reduces as the length of the password increases. If you are using the first n bits as the salt, then you are weakening the password further, as the Shannon model works on the premise that "if the first n bit is known, then how well can anyone guess the other bits". In simpler words, if an attacker is allowed to know a portion of the password in cleartext, it is easier for him to deduce the other unknown portion, because the contents of the password are not truly random.
• Now that you've stored the password fragment in cleartext, you will need to encrypt it. That sounds easy, except that keys have to associated with a management lifecycle where you need to issue them, protect them, and discard them after a particular period; getting of this right is certainly not as easy as using a secure PRNG to generate the salt and storing this random sequence of bits in the clear.

• I would consider that the entropy associated with the password is reduced by a minimum value of the entropy associated with the 8 bits; in the Shannon model of calculating entropy of user selected passwords from a 94 character alphabet, this around 4 bits of entropy. The reduction in entropy is due to the model in use - most passwords are not a sequence of random bits, especially if they are chosen from natural languages. Concatenating n-bits from the password to itself to compute a hash will quite obviously make the contents of the password even less random, thus reducing entropy.
• Using the first 8 bits of the password as the salt is in itself a poor decision, compared to using the last 8 bits, not that the latter is a good decision. It so happens that under the Shannon model for computing entropy of a password, the entropy per bit reduces as the length of the password increases. If you are using the first n bits as the salt, then you are weakening the password further, as the Shannon model works on the premise that "if the first n bit is known, then how well can anyone guess the other following bits".
• Now that you've stored the password fragment in cleartext, you will need to encrypt it. That sounds easy, except that keys have to associated with a management lifecycle where you need to issue them, protect them, and discard them after a particular period; getting of this right is certainly not as easy as using a secure PRNG to generate the salt and storing this random sequence of bits in the clear. This is irrelevant if one is not storing the salt.