Protecting against rainbow tables
To protect against rainbow tables, we add a salt to the passwords. The salt is randomly generated and stored in the database, unique to each user. In theory, you could use the same salt for all users but that means that duplicate passwords would still have the same hash, and a rainbow table could still be created specific passwords with that salt.
The salt is added to either the start or the end of the password before it’s hashed, and this means that every user will have a different password hash even if they have the same password. Hash functions like bcrypt and sha512crypt handle this automatically. Salts don’t need to be kept private.
Question 1. Crack the hash “d0199f51d2728db6011945145a1b607a” using the rainbow table manually.
You can use this website to crack this hash value
Question 2. Crack the hash “5b31f93c09ad1d065c0491b764d04933” using online tools
You can use this website to crack this hash value.
Question 3. Should you encrypt passwords? Yes/No
Recognising password hashes
Automated hash recognition tools such as https://pypi.org/project/hashID/ exist, but they are unreliable for many formats. For hashes that have a prefix, the tools are reliable. Use a healthy combination of context and tools. If you found the hash in a web application database, it’s more likely to be md5 than NTLM. Automated hash recognition tools often get these hash types mixed up, which highlights the importance of learning yourself.
Unix style password hashes are very easy to recognise, as they have a prefix. The prefix tells you the hashing algorithm used to generate the hash. The standard format is $format$rounds$salt$hash.
Windows passwords are hashed using NTLM, which is a variant of md4. They’re visually identical to md4 and md5 hashes, so it’s very important to use context to work out the hash type.
On Linux, password hashes are stored in /etc/shadow. This file is normally only readable by root. They used to be stored in /etc/passwd, and were readable by everyone.
On Windows, password hashes are stored in the SAM. Windows tries to prevent normal users from dumping them, but tools like mimikatz exist for this. Importantly, the hashes found there are split into NT hashes and LM hashes.
Here’s a quick table of the most Unix style password prefixes that you’ll see.
A great place to find more hash formats and password prefixes is the hashcat example page, available here: https://hashcat.net/wiki/doku.php?id=example_hashes.
For other hash types, you’ll normally need to go by length, encoding or some research into the application that generated them. Never underestimate the power of research.
Question 1. How many rounds does sha512crypt ($6$) use by default?
You can read this website for this question
Question 2. What’s the hashcat example hash (from the website) for Citrix Netscaler hashes?
You can find the answer in this website.
Question 3. How long is a Windows NTLM hash, in characters?
You can find the answer in this website.
We’ve already mentioned rainbow tables as a method to crack hashes that don’t have a salt, but what if there’s a salt involved?
You can’t “decrypt” password hashes. They’re not encrypted. You have to crack the hashes by hashing a large number of different inputs (often rockyou, these are the possible passwords), potentially adding the salt if there is one and comparing it to the target hash. Once it matches, you know what the password was. Tools like Hashcat and John the Ripper are normally used for this.