You use passwords? Yeah, they're important, ay. I have a few different ones on the go, a bunch of password managers and vaults, but we all know it isn't enough. You reading this right now, yes you! Your password is bad. Alas we can keep them secret and not tell our friends - then nobody will know what it is! But when it comes to the "Create Account" screen, we are happy enough to hand out our top secret passwords freely...

But not all login pages are the same. A truly secure service requires expert development, cryptography mechanisms and system administration. Unfortunately that is rarely the case...

How is my password stored securely?

First of all, storing passwords in plaintext is heresy in the Tech game, thankfully. If a popular service was found to be treating their Customers security so irresponsibly, the backlash of the Internet would be severely damaging to both revenue and reputation. Instead, authentication servers utilize one-way pseudo random hash functions to transform the naked password into a lengthy string of meaningless characters. This output, or the Message Digest, should be impossible to reverse engineer, and should be stored securely in the servers password database.

When you log into that same online service, your password field input is passed through the same hash function as before, and the resultant hash is validated against database copy.

Now clearly this hash function must be important, and it is. MD5 and SHA1 are regrettably two of the more prevalent functions on the Internet. MD5 and SHA1 date back to 1992 and 1993 respectively, and as such are supported on near all computer devices across the globe.

MD5 and SHA1 both produce fairly short digests. The 128-bit MD5 digest translates to a mere 32 alphanumeric characters. The 160-bit SHA1 algorithm's 40 characters is still on the short side (we will get to why this is bad in a moment). On that note, MD5 and SHA1 have each been proven to have a possibility of producing two identical digests from different inputs, making these hashing functions officially BROKEN! On top of that, near-complete hash lookup tables can be found online for most common password combinations, making passwords easily crackable. As such, the use of either of these functions is highly frowned upon by regulatory overlords, though unfortunately not legally enforced yet.

Updated SHA2 functions SHA256 and SHA512 (never proven to produce a collision) have outputs of the bit-length suggested in the name, resulting in hash lengths of 64 and 128 hexadecimal characters, making them much more secure. Now we will look at how dearly vital the added digest length really is...

Cracking Hashed Passwords

Because hash functions sequentially perform a large number of mathematical operations on an input in an iterative manner, reverse engineering the Secure Hash Algorithm is not possible. I have gone into this in more depth from a Bitcoin perspective in a previous post, but essentially the only plausible way of cracking a hashed password is to Brute Force it by hashing millions and millions of random guesses until you find a matching digest. This takes time.

To demonstrate, I have passed several bad passwords through a SHA1 hash and saved in a file named "DemoHashes":

skylar@SkyeNetDev:~$ cat DemoHashes 
b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1
d033e22ae348aeb5660fc2140aec35850c4da997
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
406c04a97ede5aec3158a6f40c602a2a99206075
d015cc465bdb4e51987df7fb870472d3fb9a3505
dc76e9f0c0006e8f919e0c515c66dbba3982f785

I will attempt to crack these entries using both the Brute-Force method, and a Rainbow-Table crack attack.

Brute-Force Demo

I will use a fantastic tool named Hashcat to automate the Brute Force process for me. Hashcat is one of the best Password Recovery packages around and is supported on all major platforms, though I have had great success with alternative crackers Cain and Abel, and John the Ripper.

To Brute Force with Hashcat, you need to specify the possible character-types at each position. In this example, I will target the "password" hash, which is 8 lowercase letters:

skylar@SkyeNetDev:~$ hashcat DemoHashes -m 100 -a 3 ?l?l?l?l?l?l?l?l
hashcat (v4.1.0-61-g7e18ab0) starting...

...13 minutes later

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8:password

Started: Fri Jul  6 16:40:24 2018
Stopped: Fri Jul  6 16:53:37 2018

As you can see, the pure computational power required to crack even an unsalted, lowercase password such as "password" is formidable.

A more effective way of cracking an unknown password is to use a Password List, or Rainbow Table. Rainbow Tables are extremely long text files containing a huge number of common passwords. High quality Rainbow Tables are often sourced from large security breach events, such as that of LinkedIn and RockYou.com. These breaches leaked millions of hashed passwords onto the Internet, making for incredibly effective lookup tables. A high quality Rainbow Table will also order the list by order popularity, with the most common passwords right at the top. This can make cracking a poor password incredibly fast and simple:

Rainbow-Table Demo

skylar@SkyeNetDev:~$ hashcat -m 100 DemoHashes wordlists/rockyou.txt 
hashcat (v4.1.0-61-g7e18ab0) starting...

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8:password
d015cc465bdb4e51987df7fb870472d3fb9a3505:secure  
d033e22ae348aeb5660fc2140aec35850c4da997:admin   
b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1:Password123
dc76e9f0c0006e8f919e0c515c66dbba3982f785:root  

And in round two, the RockYou Rainbow-Table was able to crack 5/6 passwords in less than 7 seconds. Because Rainbow-Tables are an accurate account of real-world passwords from production services, they capture many commonly-used password conventions. A finely-tuned and targeted Rainbow-Table can crack thousands of real password hashes in a very short amount of time.

Clearly, using common passwords is a bad idea, and you should feel bad for using them. But what really makes up a good password?

Choosing a Good Password

Choosing a password is a personal challenge, a battle between complexity and memorability. There are good reasons for making passwords complex, but there are even better reasons for making your password long.

With a simple 8-digit lowercase password of password, each character can have a value between A-Z. This results in a number of possible password combinations of over 200 billion (26⁸ = 208827064576), or rather the number of possible character values raised to the power of the number of characters. This may sound like a staggeringly large number, but even mid-range gaming PCs can calculate billions of hashes per second (GH/s). High-end Graphics Cards can perform Hash functions far more effectively, and specialist rigs with multiple GPUs have been known to reach hash powers of over 300 GH/s for weak algorithms such as MD5, theoretically brute-force cracking our example password in under a second without the use of a Rainbow Table.

The number of possible combinations increases exponentially as we add more characters:

Now adding special characters increases the number of possible values per character. You can dramatically increase the number of possible combinations by including a range of characters in your password. Here is how the complexity scales with additional character-sets:

As you can see, your password security is directly related to the number of possible character values, and you should be sure to include a mixture of cases, numbers and special characters in your passwords.

Length vs Complexity

Your password security scales with both complexity and length, but which is more vital? Well, funnily enough the Laws of Exponents mean that the number of characters has a more significant impact on the number of possible combinations.

To quantify this, a mixed-value 10-character password (E.G. "An,3xAmp!E") is in fact LESS secure (strictly in terms of brute-forcibility) than a completely lowercase password of 14-characters (E.G. "anotherexample").

But due to Rainbox-Tables and Dictionary-based word-lists, our second password here could be cracked instantly, being a simple conjunction of two English dictionary words. For maximum Password Security, adhere to the following conventions:

1. Never include dictionary words in your password
2. Use a mixture of cases, numbers and special characters
3. Avoid using names and dates personal to you that an attacker could find online
4. Make your password as long as you are able to

Following the above rules, your password may stand a good chance against database attacks, but there are methods implemented by online services that go an extra mile to secure your credentials...

Iterative Hashing

Passing a password through a hash function multiple times is a very simple and straightforward method of adding extra security to your password database. Because each hash requires time and computational resources to perform, nesting hash functions will result in a hash that would take far longer to brute force.

Because your hash is only as secure as the security of the hash functions used, it makes little sense to mix hash functions. For example:

SHA512(SHA512(SHA512(PASSWORD)))

And...

SHA512(SHA1(MD5(PASSWORD)))

The former hashing algorithm is far more secure than the latter, simply because SHA512 is that much stronger than SHA1 or MD5.

Using Slow Hash Functions

Now SHA is fast by design, but when it comes to Password Security, fast to compute means fast to crack. Slower Hash functions exist purely for this reason, which are built from the ground up in order to be very computationally heavy and slow.

Being slow is not a problem for an authentication server, which need only compute the hashing algorithm whenever a user logs into the service, but makes the act of brute-forcing a leaked hash far more difficult.

A few of the more popular Slow Hash Functions are PBKDF2, bcrypt and scrypt. All three of these functions require more work than SHA to compute, and as such are the recommended Hash functions for working with any form of user authentication.

Add Salt to them Hashes!

In cryptography, a Salt is systematically unique value added to the password to increase the length. Unlike a Nonce (a number used once), the Salt must be stored in the Password DB along with the password Hash so that the Hash can be repeated for authentication. This value could be a timestamp, a sequence number or something entirely random. The important part is that the Salt should be both long and unique. By adding a Salt to a Password, the plaintext hash input can be bulked up to 100s of characters, making the hash that much more difficult to crack:

PBKDF2(SALT+PBKDF2(SALT+PBKDF2(SALT+PASSWORD)))

This example uses only 3 iterations of Salted PBKDF2 Hashing. Common Hashing algorithm implementations in fact use thousands, or even millions, and by adding a Salt to each iteration the probability of ever cracking the hash becomes closer and closer to nonexistant.

The second a Salt is added to your Password, Rainbow Tables become practically useless. The Salt ensures that no matter how short or simple the original plaintext password was, the hash function input remains both long and complex.

All in all, passwords are an unfortunate necessity in today's online world and it is has been an interesting study delving into how they keep us secure in the real world.

Thanks for reading!