Explain Like I'm Five

I know you gotta store the passwords hashed but doesn’t that just move the goalposts?

Yes, kinda. Security isn't about making things 100% secure, that's not really an achievable goal. It's about making it so hard to break the security that it's either not possible with current technology, or at least hard enough that it's not financially feasible. Password hashing is a great example for this, which gets to your second question:

How come someone can’t use the hashed end result to get into the service it was used for?

They can, though there are technical methods for preventing this. But, there is a whole class of attacks called Pass the Hash which do basically this. This is also part of the reason that many organizations are moving away from passwords alone (or at all) and more towards things like Pass Keys (which work in an entirely different way) or Two factor authentication, which pair a password with something else (biometrics, One Time Passwords, etc.).

To dig into the details of why passwords are hashed (and salted), it's important to consider why that is recommended. This is really about slowing down an attacker's ability to get your password back from the hash. Consider for a moment that I go and compromise a website's server (say, lemmy.world). One of the pieces of information I am going to try and get away with (exfiltrate) is the database of usernames and passwords. Even better if that data is tied to email addresses. Now, if all of the passwords are stored in plain text, I can immediately start using those usernames and passwords both on the compromised site, but also on other sites across the internet. Many people still reuse passwords (or similar enough passwords that I can guess them) across different sites. Maybe only 0.1% of users will have the same email address and password used on their bank account as they do on the compromised website. For 10,000 users, that means I get to drain the bank accounts of 10 of them. If I average $1000 from each, that's an easy $10,000 I walk away with, with almost zero effort.

Hashing makes this harder and take longer. First off, there is no mathematical way for me to go from a hash back to a password, it's literally impossible. What I have to do is guess a password, run it though the hashing algorithm and see if that guess is a match. So, I guess "Password1" and that hashes to something, if it's not a match, I try "Password2" and check if it is a match, and so on. Unlike the movies, I cannot discover the password one character at a time, either I get it perfectly right or I don't, there is no information in between. If your password is "Password3", I will get no information by guessing "Password2". I'll just know that "Password2" wasn't your password. And while calculating a single hash value is reasonably quick, when the number of possible passwords I need to guess is mind-mindbogglingly big, the small increments of time add up really fast.

For example, my Lemmy password is exactly 16 characters. It contains the usual combination of upper and lower case letters, numbers and special characters. Let's call this 70 possible characters in each position. So, there are 70^16 possible passwords, that is 332,329,305,696,000,000,000,000,000,000 possible passwords (assuming my calculator isn't truncating digits, but close enough). If we assume Lemmy is using bcrypt (I haven't checked) and the attacker has several modern GPUs to throw at the problem, they might be guessing 1,000,000 or so passwords per second (maybe a bit more or less, but what's a few zeros between fiends). That translates to 3.32329305696 * 10^23 seconds of guessing, or about 10,000,000,000,000,000 years (rounding a bit). That's likely a few years longer than I will have a Lemmy account. Even if they are guessing a thousand times faster than I used in my example, it's still a really, really long time.

And so this is why hashing is exactly about "mov[ing] the goalposts". All we've done is make it take a bit longer to get my password from the hash. But that "a bit" gives the defenders time to discover the breach and get users to update their passwords. If someone gets my password hash today and starts guessing, as long as Lemmy lets me know about it and I update my password before the heat death of the Universe, it's probably fine.

There are some caveats to this. People are actually pretty bad at choosing passwords (me included). And we tend to pick predictable things and use common words or numbers (like birthdays). So, instead of guessing every possible combination, attackers can use wordlists with common changes to those words (numbers at the start or end, symbols at the start or end, replacing letters with numbers such as 1337 sp3@k, etc.) to crack some passwords faster. Which is one reason network defenders are pretty quick to pull the "please change your password" lever. They have no way of knowing if your password is "I Love Puppies 99!" or "r39%^0m'AferF@&B". The former would fall out of a wordlist attack pretty fast, the latter is in the "heat death of the Universe" territory. You can also go in for Diceware passwords. Using 4-5 truly random words can also push that password cracking time close enough to "never".

So, "doesn’t that just move the goalposts?"

Yup, it is. But when the goal posts are moved to "this will now take more time than might ever actually exist", that's plenty far enough.

Because, the hashing function is used before comparing.

• Stored hash is “5f4dcc3b5aa765d61d8327deb882cf99”,
• user sends “password”,
• system runs the hash on “password” and gets “5f4dcc3b5aa765d61d8327deb882cf99”,
• it matches, access is granted.

If the user sends “5f4dcc3b5aa765d61d8327deb882cf99” the system runs the hash on that and gets “696d29e0940a4957748fe3fc9efd22a3”. Those don’t match. No access.

Pass the hash, https://en.wikipedia.org/wiki/Pass_the_hash, is something Windows has been vulnerable to for a very long time. See also Mimikatz.

Hash functions only work in one direction. By design, the outputs are not unique, so you can't reverse it. For example, a simplified version might take any number and map it to a 1 digit number. So if you saw the result was 3, you can't know if the original number was 976 or 2265.

Everything in security does just move the goal posts though, you're right.

You can't really use the hashed password to impersonate, because whatever server logic is there to authenticate users will hash it again. But the output from that, a token or cookie or whatever, can sometimes be grabbed and used maliciously. They usually have short lifetimes before they need to be refreshed, but beyond that I don't know how the mitigations work tbh.

Another potential problem is attackers getting the hash, and comparing it to hashes of common passwords, dictionary words, etc. They apply 'salt' (changes to password before hashing) to try and make this harder.

One thing not mentioned is that modern password hashing algorithms will iterate your password hundred of thousand of times. This makes cracking the hash much more time intensive. For example if 1 hash takes 1ms (most hash algorithms are way quicker), then 1000 iterations of that means it will take 1 second to compute your hash from the input. The server has to spend that time to validate your password when you login, but that's a small tradeoff to make brute force attempts which will now have to calculate 1000x hashes for each input.

We updated to the NIST recommendation of 600000 iterations a few years ago when it was released, with regular increases every year. Logins take upwards of 5 seconds but it's added security in the event the data is leaked.

 I'm not very technical so this is how it was explained to make sense to me

A hash is basically like an identifier for a piece of data that lets you know it's integrity. You take a blob of data, run a hash of it which basically just means it takes all the data that's present, does some math magic, and spits out your hash. This is great because if a single bit changes in that data, it will spit out an entirely different hash.

Now, you can also basically make a hash of hashes and compare them, basically were another level up now. 

We can use a cryptographic key that you and I only know to encrypt and decrypt a hash of a has that we can share. 

All we send eachother is meaningless numbers, but knowing the cryptographic key, we can "subtract" that from the data we recieve to know it's content.

If anyone else intercepts that data without the key will encrypt it to find a completely different set of data 

Because the service is going to hash whatever password you provide. If you sent the hash itself, it would hash it again and get a non-matching result.

You'd think that having those hashed values might help, but it doesn't really (as long as other best practices are in place). Ultimately having someone's password is used to impersonate them, which means using the same front end to the service as everyone else.