Password encryption, hashing and salting explained with the help of a shoe [VIDEO]

Salted hashesTime and time again we hear about big companies (*cough*eBay*cough*) having serious security breaches, which result in users' private information being exposed.

When a company says it has suffered an attack that has resulted in hackers accessing its databases, there are some important questions that they should answer.

One of them is: how well were you looking after users' passwords?

If they simply say the passwords were "encrypted". Well, that doesn't really put my mind at rest.

Instead, what I would like you to explain is what algorithm you used, and whether you salted and hashed the passwords to make it harder for a cracker to brute-force them.

Unfortunately the general public uses the term "encrypted" a lot, and puts a lot of weight behind the term believing that it means that if something is "encrypted" it can't be decrypted by a hacker. But, sadly, that's often not the case.

When a password is properly salted and hashed, however, it goes through a one-way process which can not be easily reversed. Indeed, it can take considerable computer power and time to have a chance of determining a single, simple password let alone drill through a database of many millions.

When I speak to the broadcast media, I find it very difficult to explain salting and hashing in a way which doesn't make their eyes glaze over. Sadly, it can make for pretty dull TV or radio and they feel they simply don't have the time to explain it all.

Which is probably why the media tend to simply say "encrypted" and not worry about it...

Fortunately, you've read this far. Which means you're interested. And some smart people from the world of security have made short videos which explain why salting and hashing user passwords is a good idea, so I don't have to.

First up is award-winning security blogger Javvad Malik, who uses a shoe to help him explain things:

And here is Rackspace's Bret McGowen (he doesn't use a shoe, but does have a whiteboard):

I hope that helped. If it didn't, leave a comment below.

Tags: , , , ,

Smashing Security podcast
Check out "Smashing Security", the new weekly audio podcast, with Graham Cluley, Carole Theriault, and special guests from the world of information security.

"Three people having fun in an industry often focused on bad news" • "It's brilliant!" • "The Top Gear of computer security"

Latest episode:

, , , ,

14 Responses

  1. Chris Thomas

    May 23, 2014 at 8:24 am #

    Thank you Graham for this truly indispensable and outstanding security resource. I visit it every day to update and maintain my intelligence and improve my understanding of these matters.

    Christopher Thomas

  2. Julian Siddle

    May 23, 2014 at 12:23 pm #

    Excellent descriptions, thank you Graham,Jaavad and Bret

  3. Graham Cotterill

    May 23, 2014 at 2:40 pm #

    Easily understood short tutorial on what could be a mind blowing subject.
    Opened my eyes to what is needed to protect my passwords.

  4. Coyote

    May 24, 2014 at 1:03 am #

    It is funny… I've often thought of writing about this topic but never got around to it. Any way, good for you Graham, for actually taking the time (like you do about everything else, even). And indeed it is technical and dull to the vast majority of people.
    But to those who don't know, it is however something to keep in mind that while it is true that it is a one-way process, there is a way to "crack" the password. For instance, if you know the salt and the algorithm in question, you can run a dictionary attack which is exactly what it sounds: you take a file of words ("words") and run the algorithm on the hash (with the same salt), and if the result is the same, it is then the actual password. But that's why salting is so important – it gives the would be cracker more work to do and especially for longer passwords with alphanumerical and non-alphanumerical characters alike. Still, when a person can grab the password file, this is how they can be "cracked" – dictionary attacks. This is much easier nowadays of course, as computers are so much faster. But even in the older days these things could be done fairly easily and the reason is simple: weak passwords.

    • Coyote in reply to Coyote.

      May 24, 2014 at 2:50 pm #

      Need to rewrite something. Where I wrote"you take a file of words ("words") and run the algorithm on the hash (with the same salt), and if the result is the same, it is then the actual password."

      It should actually be:

      you take a file of words ("words") and run the algorithm on each WORD (with the same salt), and if the result is the SAME AS THE HASH, it is then THAT "word" (that results in the hash you are trying to find the password to) that is the password.

      As for determining the salt, it is possible (it has to be). Still, instead of having to simply decrypt (as if it were two way process) you have to run a dictionary attack (say) which you could liken to brute force, and if the password is strong enough, there might not be the actual password in the dictionary file (and those files can get really really large… even in the mid 90s they were large… of course, back then, disk space was much more expensive and less capacity, so all the more reason to use a strong password and hope it is salted!).

      As an aside, the above description is how password authentication works: it does the exact same thing except it uses the typed in password instead of a list of potential passwords. It then compares the result with what is on file.

  5. ter-ese

    May 24, 2014 at 5:12 am #

    Well done for this info Mr. Culey. I'm not learned in these matters of computer security. I'm just a regular computer user. From what I can gather from your posts it seems hacking or breaking of passwords is getting easier so should atm pins still be restricted to 4 or 6 digits since it seems the longer the pin or password the more difficut it is to break.

  6. drsolly

    May 24, 2014 at 2:39 pm #

    I feel a blog post coming on …

    All true, but doesn't really have much to do with the real problem.

    The way that people get your password, is by using the fact that
    people cannot remember 100 different passwords. And unimaginative
    security people have been telling users "don't write your
    password down", because that's what someone told them when they
    went on the two-day Security Essentials course.

    But security people have rarely said "don't use the same password on
    mutliple places", because it's only rather recently that ordinary
    users have wanted logins to several dozen places.

    And he has understood that he can't use "password" for his password,
    or "letmein". He's taken on board that he needs to use something
    hard to guess, like qidGR63*n12dskwian

    So, Joe K User uses his email address as his username, because why not?
    joekuser@gmail.com. And he uses the same password for Ebay, Paypal,
    his bank, and every web site that he visits that asks for registration.
    He can just about remember qidGR63*n12dskwian; no way could he remember
    a hundred passwords like that.

    And no-one told him "don't use the same password on
    mutliple places".

    Username joekuser@gmail.com
    Password qidGR63*n12dskwian

    Except me. I've been telling people for 25 years, "Use a different password
    each time you need one, and remember them by writing them on a
    piece of paper, that you carry in your wallet". And I give a few simple ways
    to avoid getting a problem if someone steals that paper. Like, for example,
    the way I remember my PIN numbers. I write them down, carry the paper
    in my wallet, but what I write down is different from the real number
    by a fixed amount, so all I need to remember is my fixed amount. I also
    have the code for my bike lock. I'm useless at remembering things.

    So, one day he logs in to "kittensarecute.com", registers his username
    joekuser@gmail.com and password qidGR63*n12dskwian

    And looks at all the cute kittens.

    But what he doesn't know, is that kittensarecute.com is run by some
    Bad People, and the Bad People are building up a list of usernames
    and passwords, and they sell them to Other Bad People, who run
    through the list on Ebay, or Paypal, and several banks.

    And, of course, they get hits. Despite the fact that Ebay, and
    Paypal, and the bank, are all using hashing, and salting, and
    peppering. And, by the way Joe User's Ebay account is linked to his Paypal
    account, so you can see how that goes.

    So here's the thing.

    Length of password doesn't matter, if you're cracking them this way.
    Complexity doesn't matter. Writing them down doesn't matter. The only
    thing that matters is to use a different password on each web site.

    But.

    Ebay can't force you to use a different password from your bank. Because
    Ebay doesn't know your bank password, and quite right too.
    Paypal can't force you to use a different password from kittensarecute.com

    So the answer is user education. And we all know how well that works.
    Is there another answer? Sort of.

    Web sites could force the user to choose a password that is very likely
    to be different from the password that he uses elsewhere. For example,
    force the user to have four digits included in his password. Or
    force the user to have four letters chosen from [wxyz]. So that when
    he chooses the password qidGR63*n12dskwian on kittensarecute.com,
    he isn't able to use that password on your web site. Or insist
    that the first four characters of the password are capitalised.

    Does this solve all password problems? No, it doesn't. But it goes a
    long way towards fixing the biggest one.

    • Coyote in reply to drsolly.

      May 24, 2014 at 3:09 pm #

      I'll avoid the irony (aside mentioning it) to my response to another post and you writing "tl;dr" and instead point out two things in regards to what you wrote:

      Re: "Length of password doesn't matter, if you're cracking them this way.
      Complexity doesn't matter. Writing them down doesn't matter. The only
      thing that matters is to use a different password on each web site."

      Never stolen a password file (or obtained through legal means) and ran a password cracker on it, have you? No, sorry, those ABSOLUTELY DO matter (WITH SALTED HASHES even!) in ADDITION to what you wrote: different passwords. Because, be real: even if you save other accounts the one you don't save could be critical (bank comes to mind).

      Re: "Except me. I've been telling people for 25 years, "Use a different password
      each time you need one, and remember them by writing them on a
      piece of paper, that you carry in your wallet"."

      Here's a story in the man (man = manual) page of a utility called 'passmass'.
      "On the other hand, if you have enough accounts with different passwords, you may end up writing them down somewhere – and that can be a security problem. Funny story: my college roommate had an 11"x13" piece of paper on which he had listed accounts and passwords all across the Internet. This was several years worth of careful work and he carried it with him everywhere he went. Well one day, he forgot to remove it from his jeans, and we found a perfectly blank sheet of paper when we took out the wash the following day!"

      (Note: wallets won't necessarily protect the paper, either. I've done this although it was – if I recall – cash)

      So no, writing them down is not the ideal solution, either. Better is to come up with a way that you and only you know, how to figure out the password based on the account in question. Or, if you're like me, you somehow are able to remember the most stupid of things including complex combinations of characters (two fun examples for science geeks like me: genes [including gene mutations] and chemical structures).

      Oh, yes, to be fair: Indeed, user education is a critical thing so you are correct there. But the other points I mention are very valid and critical too.

  7. Kabir

    May 24, 2014 at 3:21 pm #

    This was a much-needed article; I loved the videos.

  8. shery

    September 17, 2014 at 3:49 pm #

    Hi, Thanks for the wonderful videos, I have a doubt in implementing hash and salt, In a web application, where should we perform this entire process of salt and hash, shall we do it at client side in js or on the server side

  9. Andrew

    August 3, 2015 at 9:43 pm #

    So, how is a different SALT created for each user and why can't hackers get the list of usernames and each associated salt?

    • Per in reply to Andrew.

      August 18, 2015 at 11:25 am #

      They probably can. The salt is just a random piece of information (characters, bytes, whatever) that is tucked on the users password before computing the hash, and the salt will be stored together with the hash value. I.e. the salt is not secret. The salt prevents the bad guy from using pre-computed hash values to find your password. If the hash contains a salted password the bad guy must compute the hash values there and then, since (hopefully!) no pre-computed hash values exist for any given salt value. This makes the work of finding out a password much harder (since it should take longer to compute a hash value that to look it up in a table). And by using a different salt for every user the bad guy can only try to guess the password of one user at a time.
      So salting does not prevent bad guys or gals from cracking passwords, it just makes it much more time consuming.

      This Wikipedia article is fairly readable: https://en.wikipedia.org/wiki/Salt_(cryptography)

  10. thorlo6

    August 4, 2015 at 2:58 am #

    Thanks for the information which was not aware of. Although I am a 63 y/o computer geek, and I care for the upkeep and security for my home wifi, I was not aware of this. My take on what some were saying in the comments, is my solution to remembering all the passwords my wife and I use. I wrote them all down in alphabetical order, saved to a flash drive then encrypted the drive with bit locker and used a unique password for it. Not a great solution, but better than just using paper and ink.

  11. graphicequaliser

    October 26, 2015 at 4:50 pm #

    I'd take the password (pass), generate a 256-character salt (salt), and then store the salt in a separate field to the hash field in the database. I'd make hash = bcrypt(bcrypt(salt)+bcrypt(pass)). I know it's slow, but it's only done once when the users sets their password, and I code in C++ so it'll shoot through.

Leave a Reply