Those Tables Password Cracking Times That Scare You — Are Mostly Wrong!
Those Tables With Password Cracking Times That Scare You And Peddle Snake Oil — Are Mostly Wrong!
Meet The Mighty PBKDF2 (Protector of Wifi and Your Password)
Education and snake oil?
In cybersecurity, you get those who pedal snake oil, and others that just try to scare you. The gap is that the advice is not given in an educated way, and basically just scares people (or gets them to buy the latest security product).
These days, the chances of someone cracking your password from a hashed version is likely to be minimal. For one, the chances of getting access to the hashed version of a password is extremely low, and for two, the password is typically stored in a way that will make it extremely costly — such as requiring the cost of electricity to boil a lake (or loch, in Scotland) — to crack it.
But, still, we get them from those who aim to “educate” (aka “preach”) us on Cybersecurity. Telling us not to share our passwords or to not click on spear-phishing links are better approaches than asking us to use long and complex passwords. As humans, we kinda lose it once we go over 10 characters. And, HashCat, too, knows all our little tricks for passwords (eg we typically always have one upper case letter, and put it at the start) — where so-called complex passwords can be just as easy to crack as short and simple ones.
And, too, the days of Microsoft Windows XP are past, but some still think we are living in that world. These days, even Microsoft uses encrypted passwords with a slow hashing method. Linux, too, uses the best of breed for its password hashing, and where it would cost you your mortage for a single bruite force password crack. The industry has moved on — and has learnt from its mistakes, but some are still stuck in the past.
Ask anyone who has forgotten their Bitcoin wallet password — and I get continual questions from many people about this — about how difficult it is to recover it though brute force methods. A nine character password, for example, on a Bitcoin wallet will take you over 59 million years — and inflation is likely to have made your Bitcoins worth very little — and you will be dead!
Those scary password cracking tables!
So we get those charts that try to scare you to use long passwords with numbers and upper and lower characters are wrong in the time to crack a hashed version of a password, such as:
These tests are based on using a fast hashing method, such as SHA-1 or SHA-256, which should never be used to securely store a password. In practice, we use a slow hashing method, such as PBKDF2 and scrypt, to hash a password, or in generating an encryption key. Overall, HashCat gives a much better, and where we see that an eight-character with PBKDF2-SHA512 takes over seven months to crack:
Exponential time
In password hashing, we do not live in linear time, for us it is exponential time — an additional of an extra character doesn’t double the time, but exponentially increases it. In Figure 1, the addition of a number, for example, for a 10-character password takes us from one month to seven months, whereas in Figure 2, a bcrypt Blowfish hash actually takes over 167 million years —where the addition of a number is hardly a major factor. In fact, add an extra digit, and it will billions of years.
Most will take the cracking speed of a fast hashing method and use that. In fact, a eight-character password for a Bitcoin wallet.dat hash takes over 59 years to crack, while Figure 1 shows that it is eight hours for any characters used.
While there were large scale breaches in the past — such as with Yahoo, LinkedIn and Adobe — these were used fast hashing methods with no salt — so once cracked for one person. Those were the days of the rainbow table, and where a simple look-up mapped a hashed password to its orginal form. These days, cracking hashed passwords is a lot more costly, and requires vast areas of GPUs, and which need a considerable amount of electricity.
With a proper KDF (Key Derivation Function), we normally slow down the whole process, and can even get to a point that we can only hash just a few passwords per second, and not billions. Thus, if we select our hashing method properly, we can make it extremely difficult for someone to discover the original password. This is the same for the generation of encryption keys from passwords.
Salting, rounds and hashing
When we say that we store a hashed version of a password, we often do not mean that we use the standard hashing methods. This includes MD5, SHA-1 and SHA-256. The reason for this is that these hashing methods are fast, and where an adversary could try billions of passwords every second and try the hashed version of these. This includes using the salt value used.
The method we normally use is to use a key derivation function (KDF). For this, one of the most widely used methods is PBKDF2 (Password-Based Key Derivation Function 2). It is defined in RFC 2898 and generates a salted hash. We also add a number of iterations, which slows down the hashing process, while also disabling the usage of GPUs.
Often this is used to create an encryption key from a defined password, and where it is not possible to reverse the password from the hashed value. PBKDF2 is used in TrueCrypt to generate the key required to read the header information of the encrypted drive and which stores the encryption keys. In WPA-2 we use 4,096 iterations.
What do we need?
To perform the hashing we need a passphrase, a salt value (16 bytes), the number of iterations, the hash type (MD5, SHA-1 or SHA-512), and the number of bytes used for the output. Bob and Alice need to be using the same passphrase, along with the same number of rounds, the same hashing method and the key length. In the same way, Bob and Alice need to share the same salt value (SaltP). This is normally achieved by passing the salt value or storing it along with the hashed value.
For hashing methods, we can use MD5 for a 128-bit hash, SHA-1 for a 160-bit hash, and SHA-256 for a 256-bit hash [here]:
For a 128-bit key to be derived, we require 16 bytes, but for a 256-bit key, we need 32 bytes.
Coding
The following is the coding [here]:
import os
import sys
import base64
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
round=1000
hashtype=0
length=32
message="Hello"
if (len(sys.argv)>1):
message=str(sys.argv[1])
if (len(sys.argv)>2):
hashtype=int(sys.argv[2])
if (len(sys.argv)>3):
round=int(sys.argv[3])
if (len(sys.argv)>4):
length=int(sys.argv[4])
salt = os.urandom(16)
h=None
if (hashtype==0): h=hashes.SHA1()
elif (hashtype==1): h=hashes.SHA512_224()
elif (hashtype==2): h=hashes.SHA512_256()
elif (hashtype==3): h=hashes.SHA224()
elif (hashtype==4): h=hashes.SHA256()
elif (hashtype==5): h=hashes.SHA384()
elif (hashtype==6): h=hashes.SHA512()
elif (hashtype==7): h=hashes.SHA3_224()
elif (hashtype==8): h=hashes.SHA3_256()
elif (hashtype==9): h=hashes.SHA3_384()
elif (hashtype==10): h=hashes.SHA3_512()
elif (hashtype==11): h=hashes.MD5()
kdf = PBKDF2HMAC(algorithm=h,length=length,salt=salt, iterations=round)
key = kdf.derive(message.encode())
# verify
kdf = PBKDF2HMAC(algorithm=h, length=length,salt=salt, iterations=round)
rtn=kdf.verify(message.encode(), key)
print(f"Message:\t{message}")
print(f"Salt:\t\t{salt.hex()}")
print(f"Salt:\t\t{base64.b64encode(salt).decode()}")
print(f"Rounds:\t\t{round}")
print(f"Hash:\t\t{kdf._algorithm.name}")
print(f"\nKey:\t\t{key.hex()}")
print(f"Key:\t\t{base64.b64encode(key).decode()}")
if (rtn==None): print("KDF Verified")A sample run shows [here]:
Message: Hello
Salt: 39201abdfa19b20cd8a4b1ff7cd40273
Salt: OSAavfoZsgzYpLH/fNQCcw==
Rounds: 4096
Hash: sha384
Key: 795e5fbe3f78ca3b3e2b57cd49e928bc9bcffd26b6cc752ac037b3fdd78d2b4f
Key: eV5fvj94yjs+K1fNSekovJvP/Sa2zHUqwDez/deNK08=
KDF VerifiedConclusions
Go, on, admit it … the problem with passwords is where you give them away, and not that the hashed version of your password will be cracked! Good password hygiene is basically what you need.
Don’t put your password into Web logins from spear phishing emails.
Don’t reuse your password.
Don’t share your password with others.
Finally, organizations should never hash a password or generate an encryption key using our standard hashing methods, as there are security issues and the hashing is fast. An improved method is to use PBKDF2, which slows down the whole of the hashing process.