Why we hash passwords

Published on 2017-01-30

Clear text is not the way. But why not?!

Let's take a dive to examine why this is a problem - and what the solution could be!

Providing access

Passwords are used along with username/email to provide access to a system - I'll be talking about this with web apps and web services in mind.

Then access is granted the identity of the user is assured - we assume that only the actual legitimate user knows the correct combination.

To be able to authenticate we need to know both the username/email and the password of the user - that way when a new request is made at a later time we can indeed authenticate again - the credentials needs to be stored.

The problem with plain text passwords

When storing passwords we could just simply store the password - in a file or a database - as plain text. This would give one small advantage: We could give the password to the user (manually or automatically) if they ever forget it.

This might actually also be a disadvantage!

Passwords stored in plain text are especially vulnerable to:

  • Malicious users in your organization
  • Security breaches in your infrastructure

Furthermore the fact that you - the owner of the service - can simply look up the users passwords would mean the users shouldn't use a password that hold any value other than giving access to your specific service.


Hash functions are one-way functions that take some input and produce some - often fixed size - output. Given the same input the hash function will produce the same output and that fact can be used here.

If we put the users password through a hash function before storing them we wouldn't be able to read them again.

But when we get an authentication request we can simply calculate the hash of the the password we are given an check if the hash matches the one we've got stored.

This means that we can not give the user her password back if they forget it!

It also means that if the place we store the passwords (database, file eg.) is compromised the users credentials are not suddenly in the wild. And anyone on our inside can't read the passwords and have the credentials - they are safe from anyone - we can only check if the passwords match some input.


I'll cut this short: Don't use MD5 - don't use SHA-1 - do use SHA-2 and do it with salt! If you have bcrypt available use it!

The first two algorithms are bad/broken/outdated and can be compromised.

SHA-2 is a broad standard - it's the way to go.

salt is when you append/prepend/mix some value to the cleartext before hashing eg. and it further obfuscates the hashing.


bcrypt is a a hashing method where the hash result contains a salt and an iteration count - this instructs the checking mechanism how to calculate the exact hash, given the correct cleartext input.

The salting makes the resulting hash non-trivial and the iterations introduce a calculation cost that makes brute forcing impractical.

Storing user passwords in bcrypt format is an excellent way to go.

What's next?

I'll be making an article about the actual security in hashed passwords - with a small attempt at brute forcing some of it!

Stay tuned!