How Passwords are Cracked - # - Part 1

Let's talk about password cracking for simplicity.

You can consider it to be three ways to crack passwords.

First you've got dictionary attacks.

This is where you try all words from a massive dictionary of words, including especially common passwords that we use or humans use.

Only generally actually use of our 10,000 or so words anyway.

So a good dictionary of common words goes quite far in helping you to crack simple passwords.

Then the second type is brute force attacks.

This is where you try every single password possibility using every possible character combination.

And then you have hybrid attacks where you use the psychology of human behavior, combine it with a dictionary and brute force attacks.

So those would roughly be the three main ways of cracking passwords.

But then to dig into it in a little bit more detail in the cracking world, there are many specialist types of attacks where, as it says here, each word of a dictionary is appended to each word in a dictionary.

So you can see the input here, these words, and then you combine them together.

And in order to get passwords, you can use for cracking.

So that's a combination attack.

And then you can have rule-based attacks.

So based on the input words from a dictionary, you design rules to produce variants of those words.

So you can see here as an example, we have the input words, then based on a rule, it will change that word that's in the dictionary and produce this output.

So you can see you've got things like change it to lower case, change it to uppercase capitalized.

The first letter, the sort of things that human beings do with their passwords.

And here you can see all of the rule-based through deviations of the word password.

You can analyze password patterns.

So for example, after cracking a percentage of passwords from a site or a location, you can look for patterns, password, length, character, set, complexity mask, and feed this in to refining your rules in any good cracker will absolutely do that when they have a lot of password hashes to crack.

And you would also create custom rules as well.

If you know the source of the hashes, such as the famous Ashley Madison hack, you would scrape the company website to make a list of words that pertain to that specific field or business, or you would work out what the words were yourself.

For example, the crackers of Ashley Madison tried words orientated towards dating and gender, and those words did feature prevalently in the cracked password.

You can try at least speak as well, where threes are changed to ease and O, is a change to zeros is a common technique that people use.

You can apply least be as rules on the dictionary words that you have.

Markov chains can be applied to password cracking in general.

We know capital letters come at the beginning, lower case letters come in the middle and symbols and numbers come at the end of passwords and attack.

Are able to crack almost as many passwords assigning rules like this, as they are with straight brute force attacks, cracking can be done online or it can be doing offline.

And this actually makes an enormous difference.

Online attacks aware the cracker interacts with the cryptosystem usually a dictionary attack against a network-based service.

For example, SSA login or website login, and a tool in Kali, which you can see here supports this online password cracking.

And you can see here, some of the syntax.

So password cracking, FTP, I map pop three FTP.

You provide it with the list.

You provide it with the password and you can even use proxies as well.

How does a common tool used for online cracking and online attacks can also be just a few guesses against an operating system login.

You throw a few usernames and passwords at it and see how you get on.

But online attacks are extremely slow attacks because of the response time.

Of the crypto system, you are interacting with the crypto system, as you attempt to do the cracking and with Hydra, in this example, it will be done potentially over the internet or over a network, which can slow it down even more.

So you can be in the region of say one guest a second to maybe 1000 guesses, a second, depending on the system's response time, what sort of system is there are many various.

And most modern crypto systems and services can defend themselves against these online active attacks, because they are simply aware of the number of attempts that are being made.

So if you take any of these, for example, FTP, IMap, pop, SSH servers that would receive this sort of attack sort of defense that they might have is to block the IP of the attacker, wants a certain number of attempts have been made.

They could also be. Inform the user of an Imap, account and email account that something is wrong or they could inform the administrator and they could even lock the accounts out and they would lock the accounts out.

If it was something like an operating system.

If you made too many attempts to log in to these defenses, all help try to mitigate these active online attacks.

And although these online attacks are common, they're only successful against very simple usernames and passwords like username, admin, password passwords.

We you get these sort of online attacks consistently against our servers.

And that's not unusual for anyone that's on the internet.

And I can even see when I look at the logs, which tools are actually using based on the traffic, because these tools give away a signature Hydra, for example, is quite easy to tell that they're using.

And of course the usual defense is to block the IP address.

The attacker then automatically changes the IP.

More than likely to proxies, especially if they're using Hydra or they could change it because they've got a bot net and then they keep trying to crack the login.

The noble defense is then to block that IP again, and you keep doing that back and forth, back and forth until they go away.

And this is all automated, both sides.

And with strong passwords, they do never to succeed because the passwords will never be correct.

And with online attacks, they just simply cannot try enough usernames and passwords.

To crack systems with complex passwords.

So that's the online attacks.

When you get to interact with the service interact with a crypto system, and then there are the offline attack where the attackers have access to the password.

Hashes. There is no interaction with the crypto system.

The cryptosystem cannot defend itself. It is just a case of trying to convert these hashes.

These are examples of hashes with the various hash types and convert them.

Into their actual plain tax value, which you can see here as an example, this is a file of usernames and the hashed password.

Something that will often be within a system in order that people can log on.

We talked about hashes and passwords in the crypto section, but let's revisit storing passwords in clear text is massively insecure.

This here should never be the actual password.

When it is stored in a system, but people still do do it.

I was using a system the other day and the admin was able to give me the password of an account, which shows that hashes are not used.

This is because hashes are one way functions once a password. Is put through a hash.

It is converted to this fixed length string like this, and it cannot be converted back to its password.

It can only be attempted to be cracked.

This is why they are better to use than clear text passwords.

The idea is if they are stolen, they still need to be cracked.

If they're in plain text, then they don't need to be cracked over.

And in order to confirm someone's login, they either send their password and you convert it to a hash and compare it.

And from the comparison, if it's the same, then, you know, it's the correct password.

Or the user actually sends a hashed version of their password.

And the two hashes are compared that is obviously the more secure version to send a copy of the hash.

And this all happens behind the scenes on many systems.

And we've got a website here where we can put data or input into the web form and run it through one of these hash functions can see we've got all these here, so let's do it with SHA1 try password hash.

And there we are.

That's the hash of password using SHA1 of everybody who uses the word password as their password and SHA1 is used.

This will be the hash.

And you can see here, we SHA1 it's quite short. Relatively.

If we were to use SHA512, you can see this is much larger and therefore harder to crack.

Here we have a form that enables us to enter input and it will run it through the PB K D F two hash algorithm, which is the password base key deviation function.

And number two.

So let's put in our password as password and we'll press this. In the real world add on good systems, passwords are often concatenated with a random and non secret value called a salt.

To see this in here, that's what this would be here and we can change its length.

So let's call it salt one, and this would be stored with the password hash.

So that's hash it. And there we are.

We get our hash based on this hash function now, because this is salted.

It has been concatenated with this value.

So if we change this.

It would mean a hash value would be different even though our input is the same.

So that's hash that. And we can see we have a different hash.

So because users have different souls, it is not feasible to store tables of pre-computed hash values of common passwords called rainbow tables to make it faster, to crack the passwords, which is why people salt.

Passwords, but salt aren't quite as useful as you might imagine.

Almost no one uses rainbow tables anymore in the real world when it comes to cracking anymore.

This is because the file size for the tables have just become too massive and are less useful.

Now that GPU based cracking is possible. GPU's offer much better performance over CPU for cracking password.

Salting does nothing to slow down the cracking of a single hash and does it little to slow down attacks on a small number of hashes.

When you're trying to protect a lot of passwords, say for example, you're the owner of a site with many thousands of users.

Salts are more useful as a defense that they are less useful than people think this is because when you crack a large number of passwords, like for example, the Ashley Madison website or the websites or wherever they come from, a large percentage will be cracked quickly because when you have a large number of passwords, many as is the name.

Human beings will simply be poor, even if there's password policies.

And then that leaves you with a shorter list of passwords.

And when you have a short list of passwords, salts become less of a useful defense.

Hence why salting? Isn't a strong mitigation to slow down cracking, but salting should still be using.

Security architects when designing solutions for authentication who know what they're doing.

Use key stretching functions also called key Derivation functions, such as this one here, PB K D F 2. And also Bcrypt is good and Scrypt is good as a key to Derivation function.

And what they typically do is use repeated invocations or iterations of a cryptographic hash to increase the time required to perform brute force attacks on stored password digest.

And this is how you want your password stored.

Not that you have preference most of the time.

And with this, I can show you exactly what I mean.

So what we can do here is we can give this 10,000 iterations.

And what that'll do is it will take this password. It'll run it through this hashing algorithm concatenating with this salt value produces output, which is the hash key.

It'll then take the hash key and run it through 10,000 iterations or however many we decide to. Hash.

And then that gives us our hash value.

So if we change this just by one, we will still get a different hash.

If the system or site you use uses a good key stretching functions such as this one and your password is complex.

Even if someone steals the hashes, your password will take impractically too long to crack, even with extremely powerful machines and nation states behind the cracking.

One way to make hashes even more secure.

And this is now getting a little bit deep in terms of the crypto is to use another secret key to encrypt the hash while it waits in the database, ready to be potentially stolen.

So we would take this hash.

We would not store this.

What we would do is we would make this as input to a round of encryption before we stored it.

And this would be encrypted with app master password encrypt.

And then finally we have our encrypted hash, which has been salted, is used a key stretcher is had 10,001 iterations.

And then it's been encrypted with AES and a master password, but the trick there.

Where to store that master password that we've encrypted this hash with. Ideally it would be on another server or location separate from where you store the actual resulting value, the resulting hash.

If of course you can afford it, but the best way is using something called a hardware security module.

Which is what you can see here, which is where you would store the master password or with some HSM's they actually do the processing for you and the password doesn't leave the HSM and these HSM can be big, old, powerful, expensive servers like this THALES.

Oh, you can see this rack mountable one.

Or you can get little ones like this, this nitro key HSM at 50 euros, which you could use for storing your own passwords, or if you've got your own server, you could potentially use it as a HSM and the second way to encrypt the hash to make it more secure.

Is to include a secret key in the hash using a keyed hash algorithm, white H Mac.

So here would be the password.

We have the master password, and then we'd have a hash algorithm and iterations and our salt.

And there we have our resulting HMac.

Unfortunately, people, even security professionals don't understand the nuances of password hashing encrypted.

So often passwords are stored with weak hashes.

And that's just the reality of the situation.

Another reason why you don't really want to share your password among sites, especially not with accounts that you care about.