Is it good to hash the password or encrypt it?

Question

Possible Duplicate:
Difference between Hashing a Password and Encrypting it
Hashing vs. Encrypting Passwords

I tried hashing my password in C# using Rfc2898DeriveBytes by passing the username as its salt value.

public string HashPassword(string HashedUsernameSalt, string Password)

{

    Rfc2898DeriveBytes HashedPass = new Rfc2898DeriveBytes(Password,
    System.Text.Encoding.Default.GetBytes(HashedUsernameSalt), 10000);
    return Convert.ToBase64String(Hasher.GetBytes(25));
}

The above method gives me some hash value. My questions are

Is it possible to get back my password back for showing the user if he forgets it? or Do I need to implement some other concept here like encrypting and decrypting it?, but I heard hashing is better than encrypting.

Thanks!

in a perfect world: hashing = 1 way scrambling that's impossible to reverse. encryption = 2 way scrambling so that you can get back what you put in. for passwords, NEVER encrypt. ALWAYS hash. if a person forgets their password, that's their problem. hash a new one and move on. — Marc B, Jan 24 '13 at 19:25
Hashes are usually 1 way. The idea behind hashing is to compare another hash to a stored hash. This way, if the hash is retrieved, the attacker cannot enter the hash into a password field, and gain access. — crush, Jan 24 '13 at 19:25
I always put systems that can tell me what my password is on immediate suspicion. I always then immediately change my password to something that I've never used before, if I even continue to hold my account on that system. — squillman, Jan 24 '13 at 19:27
Don't use `Encoding.Default`. That's system dependent and can't work on many characters. Use `Encoding.Utf8`. — CodesInChaos, Jan 25 '13 at 11:14
Sorry, but you are on your own on this one. I deleted my answer. Obviously it's not allowed to post answers here with links to the MSDN documentation. Sad to see what's going on at this site sometimes... — Guffa, Jan 25 '13 at 11:51
Not sure it was the MSDN bit that got your downvotes, more the mistaken guidance on secure algorithms for hashing from what I saw :-) — Rory Alsop, Jan 25 '13 at 12:00
@Guffa I didn't downvote for linking to MSDN. I downvoted for recommending an inappropriate cryptographic scheme. Simple SHA-1 is fine for some purposes(though I'd prefer SHA-2 for those), but password hashing is not one of them. For password hashing you should use an expensive construction, such as `Rfc2898DeriveBytes` aka. PBKDF2. — CodesInChaos, Jan 25 '13 at 12:58
@CodesInChaos - I replaced my code with Encoding.Utf8. Very useful tip! Thanks mate. — Renish B, Jan 25 '13 at 14:37
username as salt BAD IDEA! If the salt is too short, an attacker can build a lookup table for every possible salt. For example, if the salt is only three ASCII characters, there are only 95x95x95 = 857,375 possible salts. That may seem like a lot, but if each lookup table contains only 1MB of the most common passwords, collectively they will be only 837GB, which is not a lot considering 1000GB hard drives can be bought for under $100 today. For the same reason, the username shouldn't be used as a salt. — Sebastian 506563, Mar 12 '16 at 17:07

score 7 · Answer 1 · answered Jan 24 '13 at 19:26

7

You should definitely use one-way hashing for passwords. Your goal shouldn't be to be able to retrieve it if the user forgets it. The thing to do would be to allow the user to reset their password (after going through some kind of identification process) to an entirely new password.

answered Jan 24 '13 at 19:26

itsme86

19,266
4
41
57

you might want to add a bit about using salts. – Woot4Moo Jan 24 '13 at 19:27
Thanks dude I hope Rfc2898DeriveBytes hashing is good enough? – Renish B Jan 25 '13 at 03:48

score 4 · Accepted Answer · answered Jan 24 '13 at 19:26

You cannot reverse a hash, so no if the user forgets his password it is "unrecoverable". You do not want to store encrypted passwords in a database, instead you do want to store those hashes. If a user forgets their password you generate a new temporary and secure password (after proper identification that the user is who they say they are).

Passwords should be hashed with a salt, else they are broken by rainbow tables quite quickly.

score 0 · Answer 3 · answered Jan 24 '13 at 19:27

it is indeed much better from a security standpoint to hash passwords instead of encrypting them. You have to manage the key you use to encrypt passwords, and if you fail to keep it secure (which you probably will against a determined attacker) then the attacker can get all of your users passwords in plaintext.

if you want to provide a forgotten password mechanism, it is better to send an e-mail to an address on file and let the user create a new password. Or implement security questions. or do both.

Is it good to hash the password or encrypt it?

3 Answers3