18

Alright, so I know this may sound dumb, but I'm having a hard time understanding what an encryption would be since it's different from a hash. I've read up on it, but I'm still not quite sure. So, I was hoping you guys could help me with it.

Anders
  • 65,052
  • 24
  • 180
  • 218
UnderMyWheel
  • 351
  • 1
  • 13
  • 3
    See: [What is a good analogy to explain to a layman why passwords should be hashed?](http://security.stackexchange.com/a/63421/2264) and [Why are salted hashes more secure for password storage?](http://security.stackexchange.com/a/51983/2264) – tylerl May 08 '16 at 03:27
  • Please note: a salted hash is much much more secure than an unsalted one. – noɥʇʎԀʎzɐɹƆ May 08 '16 at 16:53

2 Answers2

26

Encryption vs. Hashing

Nobody really "encrypts" a password, although you could... but you'd be encrypting it with another password, and you would need that password to decrypt the first password. When it comes to passwords, we normally hash them.

  • Hashing is simply one-way. You cannot get the string back, you can only check to see if a string validates against a hash. If your string validates against the hash, this does not guarantee that it's the same "password," but you can log in with it because you've found a collision. The "message"/password is usually limited to a small number of characters, relatively speaking.

  • Encrypting is two-way. For example, you have an algorithm, a key, and a message. Using the key, you can unlock the message. Usually, the message could be of arbitrary size.

Makeshift Flowchart Examples

I made a couple flowcharts that are overly simplified. Hope it helps.

hashing

See the above? It doesn't make any sense that you would get the "message" back. Why? You're already entering the password, which is the "message" itself.

Now look at this:

encryption

With encryption, you're getting the decrypted message back if the decryption key is correct. You use the key to unlock the encrypted contents.

With hashing, you already have the "message" if it validates, or a collision. What you enter is the message.

Mark Buffalo
  • 22,508
  • 8
  • 74
  • 91
  • 1
    Thanks, I now understand the difference between a hash and encryption! :) Before I wasn't really sure what the difference was, and I wasn't sure if I should keep hashing passwords with a salt or encrypting them. But now I fully understand the difference. – UnderMyWheel May 08 '16 at 01:34
  • Heh, I've been there before! :) Use bcrypt. :D – Mark Buffalo May 08 '16 at 01:35
  • I've been there before [Why do websites store passwords' hashes not their ciphertexts?](http://security.stackexchange.com/questions/105189/why-do-websites-store-passwords-hashes-not-their-ciphertexts) – Ulkoma May 08 '16 at 07:17
  • Or you could just encrypt the password with something arbitrary as the key (that you don't save), and suddenly it's like you've hashed it... – user541686 May 08 '16 at 08:08
  • @Mehrdad see the link I posted – Ulkoma May 08 '16 at 08:28
  • 1
    @Mehrdad With an arbitrary key you wouldn't be able to verify if the same password was entered again and therefore you basically just created data garbage ;) Except, of course, if you create the encryption key from the passphrase, in which case you _are_ hashing. – Sebb May 08 '16 at 09:21
  • @Sebb: Yeah, it's past my bedtime... I shouldn't have tried to comment haha. – user541686 May 08 '16 at 09:27
  • For convoluted reasons, I'm considering a secret encryption scheme... using the approach you overlooked: public key encryption. Unfortunately it's not especially helpful as an alternative to hashing as the resulting block apparently isn't guaranteed to be repeatable due to optional padding. – Kaithar May 08 '16 at 14:16
12

A hash is an irreversible process: one function, 'hash' which cannot be "reversed". Once you have a hash, you can only guess the original password via a brute force attack, which involves hashing a variety of possible passwords until you end up with the same hash value, which indicates that the password you guessed is the same as the original.

Encryption is a reversible process: two functions, 'encryption' <-> 'decryption'; that which is encrypted can be decrypted if you have the key; decryption recovers the original password without guessing.

The security of a hashed password depends largely on the amount of computation required to perform the hash function. The more computation required, the longer it takes; since a brute force attack must repeat that computation for thousands or millions of possible passwords, the longer each individual hash computation takes the less practical the attack becomes.

The security of an encrypted password depends on the soundness of the algorithm and the secret of the key.

The benefit of hashing is that no key is required, which improves the overall security of the system - one less secret piece to be kept out of the hands of the attacker.

gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • For us non-native speakers: **hash(ing)** means to cut pieces of food (eg. meat, salad, vegetables) into small pieces (= hashes). You cannot convert the small pieces of food back into a solid piece of meat/salad/vegetable :) https://en.wikipedia.org/wiki/Hash_%28food%29 – Juha Untinen May 09 '16 at 07:21
  • "which indicates that the password you guessed is the same as the original". Hash is generally not an injection, that it, there are different values for 'password' that give the same hash. You may say "which indicates that the password you guessed has the same hash as the original password", that it other password can works !. – Orace May 09 '16 at 08:59