Join Now / Sign In
Ask a Question
The term that I'm familiar with is a "salty hash" which is what I believe you are referring to. The hashed part means that when a login is created for a system, their corresponding password is not saved as plain text as it appears IT world may be doing, since they just emailed me my password. Instead of plain text, the password is hashed using an algorithm like MD5, so if your password was "bob" the hash might look something like FE12AFZE.... Hashing is a one-way cryptographic strategy, you cannot directly get "bob" back from the hash value.
This is a good first line of defense as it makes it more difficult for the password to be exposed to a malicious user. The problem is that the strong hash functions like MD5 have already been brute force attacked, so you can find or create a reverse lookup and get "bob" back out from the hash.
This is where the "salted" component comes in, where each user is assigned a random salt value that is appended to their password prior to hashing, thus making the brute force attack that much more difficult.
The way that the application can authenticate a user, even though it doesn't have the ability to read their password is by following the same steps that were used when creating the login. The user must provide their username and login to get access to the site, from the user name we can identify their salt and their hashed password, we append the salt to the password they provide and then hash it. From that result we compare it to the stored hash password for a match. With hashing, the odds of two different keys (paswords) is statistically unlikely, so if we don't have the same hash value, then they did not provide the correct password.
I'm sure you can find .net code examples by searching ".net salty hash".