-1

I know that hashing is a one way function and encrypted messages could be retrieved if you know the corresponding key to which you encrypted the message. Other than the ability to retrieve, what advantages/disadvantages are there in hashing over encryption?

  • 9
    There is no "advantage". They serve completely different purposes. – Ayrx Jun 3 '14 at 14:45
2

As has been mentioned, hashing and encryption serve different purposes, so this question would be better phrased with an application in mind. For a real life example that is commonly used, a website developer might ask: "I am creating a website where users need a username and password to login. Should I store the passwords in plain text somewhere, should I encrypt the passwords, or should I hash them?" The answer to this question will depend on what the website is for and who the users are, but typically it goes like this:

  1. Plain Text Passwords: this should usually be avoided, except for extremely low security sites where the passwords are auto-generated. If the users are allowed to create their own passwords, you should just about never store them in plain-text, because some users will inevitably use the same password for this site as they would for sites with high-security, for example their bank accounts or other email accounts where bank account password reset emails would be sent to.

  2. Encrypt the Passwords: this is MUCH better than plain text passwords, however someone will always have the ability to decrypt the passwords. This is because in order for the web server to authenticate the passwords, it must be able to decrypt the passwords which means that the decryption key must be stored somewhere the server can access. Consequently, anyone with access to the server will be able to decrypt the passwords as well. That person might normally be the web developer or an IT admin who is trusted, but it's usually best to not have anyone be able to decrypt the passwords. Furthermore, if the server is somehow compromised, then the hacker can decrypt everyone's password.

  3. Hashing the Passwords: this is typically the best method since even if the server is compromised, the passwords are still protected (within reason). The main disadvantage of this is that it is not possible to recover a password; you can only reset your password.

Moral: if your bank has a "Forgot Password" recovery mechanism on their website, and they email you your password that you forgot instead of resetting it for you, then you should switch banks.

0

There is no advantage , they serve different purposes as Terry Chia said.

In "log in systems" you want to make sure that if someone manages to "steal" your database the attacker won't be able to actually read the password, but only the hash of the password, since many users use the same passwords for many different sites. Then if an attacker managed to crack stackexchange's database , he would be able to use the same password to email, ebanking etc..

Imagine the scenario where what you want is to make sure a message when transmitted from a sender X to a receiver Y ,is received correctly and the receiver Y can verify it was received correctly and none altered the message, also you both have already decided on a key for the hash function.
You don't care if an attacker read your message. So you just send the clear-text , with a hash of that clear-text, then the receiver will hash the received clear-text with the same key and if the two hashes are the same he will be able to verify that, the message received was not altered.
All you care is that your receiver can verify it was send by you.

0

If you want to think about it in simpler terms: Hashing is like matching a finger print whereas encrypting it is to scramble the message. Use hashing to determine if the message/file is authentic. Use encryption to protect/hide the content.

0

Elaborating on the functions both serve:

Hashing is, as you said, non-reversible. It is also constant. This is why we use it to store passwords. When you set your password for, say, your e-mail, the server never stores it (well, some do, but they deserve a certain degree of public shaming). Instead, (assuming your password is "password") they store h("password"). Now lets say you want to log in. This is where encryption comes into play. You and the server go though something called a Diffie-Helfman key exchange, which lets you exchange a key with the server. Now you use that key to encrypt your password (x = e("password")) and send it to the server. The server, since it has the same key you used to encrypt your password, can perform the function e^-1(x). Now it has the plaintext of your password. If we were talking about Heartbleed, this is is the most likely point for your password to be stolen. Anyway, now the server performs the function h("password") and compares it against the stored password hash it has associated with your username. If the hash they generated from the value you sent them matches the one that they have, they allow you access to your account.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.