# Salting password with the first 8 bit of the password itself

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?

-
Germans used similar thing with Enigma and we all know how it ended... If you don't want to use random salt, use service name + user name. – Hubert Kario Jul 12 '11 at 0:28

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:

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

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

-
I think you make the completely flawed assumption that @Mohamed wants to store the salt as plain text. The reason a salt is stored plain text, is that it is necessary when calculating the hash for a given password. If the password is given (for calculating the hash), the salt is automatically there, i.e. no need to store it! – Peter Smit Jul 12 '11 at 8:30
@Peter, see my comment to Paul's answer. I'm aware of the fact that the salt need not stored. That itself means that a hash chain computation is feasible, and that the salt has lost it's property of being a cryptographic salt. – Vineet Reynolds Jul 12 '11 at 8:37
Yes, I know. That is the reason that his method is not good enough, not as this answer claims because the salt will be stored plain text and therefore revealing information of the password. So I would advise you to change your answer. It does not deserve to be the top voted at this time. – Peter Smit Jul 12 '11 at 9:34
@Peter, I believe I've addressed your concern, while retaining my original answer that assumed storage of the salt. – Vineet Reynolds Jul 12 '11 at 10:14

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.

-
+1 for pointing out the loss of protection against rainbow tables. Of course, the attacker must still compute the tables as opposed to using a downloaded set of hashes, but he must do it only once. – Vineet Reynolds Jul 12 '11 at 4:21
@Paul, well said. Not only is it no better than no salt -- it is actually worse, for the reasons @Vineet explained (it decreases the entropy of the password, since the salt needs to be public). – D.W. Jul 12 '11 at 4:46
@dw, salt not need to be public since we are not storing it at all. it is generated by function. – Mohamed Jul 12 '11 at 6:22
@Mohamed, read the last sentence in the answer - `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). – Vineet Reynolds Jul 12 '11 at 7:38