Is it possible to get the salt from the password and then use the hash of the password + the resulting salt?
I am using NHibernate and have a special type to encrypt passwords in the database so that I can use string properties to represent passwords, but NHibernate converts / encrypts the value before storing it in the db. I am currently storing the salt value and encryption key in a config file, but I would really prefer to go to the password hash. However, the NHibernate custom type doesn't know anything about the object being stored other than the property value that is being passed to it, so I can't generate some random salt and store it with an object in another property from that custom type.
Since I can't store the salt separately, I'm wondering if it would be okay to infer the salt from the password itself and then hash the combination of the two. For example, I can take a password, MD5 hash, and then use the MD5 hash as salt. Everything will be good? This would allow me to determine a constant password by using a unique (but derived) salt value per password, but are there any security considerations when doing this?
EDIT:
Since all the answers I have received so far have not taken into account the context of the question, let me introduce the signature of a method defined in terms of NHibernate.
public override void Set(IDbCommand cmd, object value, int index)
{
var param = (IDataParameter)cmd.Parameters[index];
if (value == null)
{
param.Value = null;
}
else
{
var temp = value.ToString();
var encrypted = encryptor.Encrypt(temp);
param.Value = encrypted;
}
}
This is all NHibernate gives me. I am getting IDbCommand object, parameter value and index. I don't know anything about the parameters themselves or the type of the object that is being saved. I only have value. I can't create a random salt and store it in a separate property because I don't know what properties exist on the persisted object and what order they are stored in the parameter collection. My goal is to hash the password in the most secure way in the context of this method call . If you try to object to my proposal, it would be helpful to get an alternative idea in this context .
source to share
Not! If you get salt from a password, the same password has the same hash and the salt becomes useless.
Try
var temp = value.ToString();
var salt = generateRandonSalt();
var encrypted = encryptor.Encrypt(temp + salt);
param.Value = salt + encrypted;
With "+" I mean the concatenation operand or something compatible with your value. And naturally, you need to always know the length of the salt so that you can check the password next time.
source to share
The purpose of the hashing function is to deduce something from the password. If you get the salt from the password, then this output is actually part of your hashing function. You just changed / added the hash function and don't really have a salt.
Salts should be random.
Their job is to make it more difficult to force a password. If the salt has 65536 different values (for example), it means that the same password can hash 65536 in different ways. If someone wants to build a dictionary that reverses hashes back to passwords, their dictionary would require 65536 entries for just one password.
The salt should have nothing to do with the password for this idea to work.
source to share
The problem with your example is that if any attacker wanted to find a match, they could create a rainbow table in which all passwords are salted with their md5 couterparts.
The salts must be unique for each record, so the hacker would have to have a reverse engineering table of all possible combinations of md5 with every possible salt.
source to share
If the goal of your salt-like scheme is to make the password resistant to dictionary attack using predefined hashes, your approach might be slightly more secure than a failed hash, but not as secure as using a valid salt.
One of the important security benefits of a valid salt is that two instances of the same password will have two different hashes. According to your scheme, knowing the password and hash of one user would allow an attacker to deduce the same password of another user with the same hash.
source to share