How hackers crack passwords
- 01 Oct 2019
- Business Security, Data Breaches, Web Applications
More and more companies are victim to data breaches every year, these breaches can range from sophisticated multi-pronged attacks. To simple and easy ones such as TalkTalk’s 2015 SQL injection breach (TalkTalk SQL Breach).
The truth of the matter is these breaches are arriving to our shores at a rapidly increasing rate, they are becoming more expensive and time consuming to deal with.
Recent figures suggest the average data breach is costing companies millions of pounds, and that doesn’t even take into account the long lasting reputation loss.
Data leaks come in all shapes and forms, and defending against them requires thinking and acting like a hacker. Expect all user input to be malicious and assume the most sophisticated hackers are trying to breach your security, because they most certainly are.
What exactly is a password hash?
To explain how hackers crack passwords, we must first cover how passwords are hashed and stored in a database. So you might be asking “What exactly is a hash?”. To put it simply it’s an algorithm that converts a string of text into a random string of letters and numbers using complex mathematics, the reason it does this is to obfuscate the original text.
You wouldn’t want an attacker to compromise a database and have all the passwords in cleartext (Clear Text Offenders), this is why we use hash functions. Let’s take a look at what this looks like in practice.
It’s important to separate a hash function from standard deviations of cryptography (Symmetric and Asymmetric Encryption), they are often mixed up or mistaken for one another. Hash functions are a one way system, you provide some input, run it through a function which then gives you an output. It’s intended to be irreversible (But this does not mean we cannot replicate the process). This is considerably different to standard public key cryptography, which is reversible. Meaning the data is encrypted with a key, then decrypted with a key. Hash functions do not work like this, the data passes through the function and cannot be passed back through the function to return the plain text.
Consider the following table:
You can see from the output, words and phrases can be churned into the hash function to give us the intended hash. However when they pass through the hash function they produce a completely different hash, even if some of the passwords look similar.
GPU accelerated password cracking
Now that we understand how hash functions work. Let’s dive deeper into how malicious users crack hashes.
Scenario: A computer hacker has used an SQL injection to extract the contents of a password database. The password database file has been downloaded for offline cracking, it contains millions of unsalted password hashes which need to be turned back into their plaintext equivalent
So how could the attacker achieve this? The vast majority of semi-skilled hackers will use tools such as oclhashcat or johntheripper to guess as many passwords as possible. Often using wordlists and brute-forcing techniques. How this works is they detect what hashing algorithm is being used via identification tools. Once the hashing algorithm has been identified they can attempt to crack them. Usually they will use wordlists containing many millions, or billions of passwords and simply pass these through the hashing function. If the hashed result looks the same as the password hash obtained, then it’s a match.
Imagine the attacker was attempting to crack the password hash ‘6f969431ae6c31575206f3caeb73dee1’. The attacker would likely be using a wordlist as the default approach, during the process of hashing each of the words in the wordlist. The tool hashes the word ‘Letmin1234’ which equates to ‘6f969431ae6c31575206f3caeb73dee1’. The attacker now knows that the password’s plaintext equivalent is ‘Letmin1234’.
Where does this process of password hashing go wrong?
The answer to that question relies on the competence of the people implementing the functions of password storage. A number of errors can be made during this process, mainly:
- Not using strong hashing algorithms. (Such as bcrypt, Argon2 and scrypt)
- Using a “quick to compute” hashing algorithm (such as MD5) means attackers can make many millions, often billions of password attempts a second.
- Errors in the password storage function, such as not applying a salt (More on this in a moment). Makes it easier for attackers to crack the passwords, as they have not been modified in any way before being passed to the hash function.
- Not applying HTTPS to the website, allowing attackers to eavesdrop on passwords as they are sent over the internet.
- Not sanitizing the user input from username/password fields. Allowing attackers to use SQL injection techniques to either steal password hashes, or bypass the login function altogether.
Errors such as these are extremely common, allowing a security professional to assess your security posture can ensure your safety. Password storage functions should be closely scrutinized and tested by qualified professionals.