Managing cybersecurity's legendary pain point: Passwords
Passwords are probably the biggest pain for us in our job. The interesting part is that for the last 14 years, many experts have been saying that passwords will disappear, but despite all the new authentication technologies, passwords are still around and probably will stay with us for a long time. Therefore, as security experts, we need to constantly look for innovative ways to protect against password-based attacks and that's why, in this chapter, we will review the most common types of attack and how to protect you and your infrastructure against them.
Password breaches
Nowadays, it is becoming a very common sight to see a new data breach (exposing the emails, usernames, and passwords of millions of users to the internet) almost every month or week. Therefore, while you cannot control the level of security that other companies put on your personal data, there are some extra steps that you can take to prevent being impacted by those attacks.
Note:
If you haven't already done so, check whether your account has already been compromised. You can do this on the famous site https://haveibeenpwned.com and https://dehashed.com/.
One of the cool features that you can find on those pages is the ability to search by email, user, or even by a password. Also, those sites will tell you some very interesting information, such as the name of the hacks in which your data was exposed, username details (in case the site uses a custom username instead of an email), and the hash of the compromised passwords.
Defensive measures
I was struggling to decide whether I should add this step or not (because this may be obvious for a pro like you); however, if I don't add this, some people may call me out on this, so here it is: If your password is found on any of those sites, then change your passwords (all of them):
- Use or enable multi-factor or multi-step authentication when available.
- Migrate to stronger password-less solutions when available (such as Microsoft Authenticator).
But wait, Cesar, aren't you going to recommend password vaults? Actually no, because a password vault will not help you in these kinds of attacks because it doesn't matter if your password is CesarRocks or Iam_having-a.greattimereadingthisbookin2021 because both will be disclosed in the same way, as a hash that may look like this: 31b54027af2ed2299b2bd7fda556d782.
Tip
Do you want to decode a hash? You may use a page such as https://md5hashing.net/hash, which uses hash matching (dictionary tables) to decode a hash.
Multi-factor versus multi-step authentication
There are still people who use these two terms interchangeably, but as a master in security, you must know the difference.
Multi-factor means that you are using at least two different factors during the authentication process. This includes the original three (something I know, something I have, something I am), plus two more that researchers are introducing: somewhere I am (this is enabled by geoposition and geofencing technologies) and my personal favorite, something you do (this is enabled by IoT devices).
An example of this will be your bank asking you to move your writs to the right to authenticate. This movement will be captured by the accelerometers in your smartwatch and that data shared by using a secure API with the bank.
Social engineering attacks using compromised passwords
This is an interesting attack because it requires no technical knowledge on the part of the attacker, which makes this a very common and dangerous threat.
Here, the attacker gathers email/password combinations from published password breaches and uses them to trick people into believing that they have been hacked for a long time and that the hacker contains sensitive information about the person. There are several variants of these attacks that vary from telling the victim that the hacker accessed the webcam and have compromised videos/photos of the victim, or that the hacker got access to the browsing history and that it will publish the victim's "dirty" website history unless some payment is made.
Figure 1.7 – Example of a scam email
As a security expert, you may have fun when receiving an email like this one, but remember, as a professional, your mission is to help others from falling victim to these kinds of attacks, from family and friends to coworkers, and especially high-end targets, such as executives of your company. The best way to deal with these kinds of attacks is through education. In fact, user education is one of the keys pillars for any cybersecurity strategy. This topic is so important that I decided to create an entire chapter for you!
Tip
Use your social media as a tool to let others know that this is a hoax. Try to post something related to these kinds of attacks on your LinkedIn, Facebook, and Instagram accounts at least every 3 months. This simple act may save your friends a lot of trouble and money while helping you to grow your social eminence.
As a cybersecurity expert, you have great powers, but also great responsibilities.
Brute-force attacks
One of the most common attacks on passwords is brute-force attacks. By far the most famous app to achieve this is John the reaper, in which you can customize the attack to reduce the time required to expose a password.
In these types of attacks, password complexity (and size) matters, so let me use some math to prove it.
We have two variables: the spectrum of possibilities (S) and the password length (L). In the alphabet, we have 26 characters, so it means our spectrum of possibilities is 26, but that is considering just one case, because if we use lowercase and uppercase, then it increases to 26+26 = 52.
This means that if we have an 8-character password (L) with just lowercase letters (S), the number of possibilities will be SL, or, in this case, 268, which means around 200 billion combinations.
Some of you may think that 200 billion is a huge number of possibilities to guess, but a modern computer can guess 100 billion combinations every second, which means that our 8-character password with just lowercase can be cracked in 2 seconds.
But no worries, all we have to do is to increase the spectrum of possibilities (S) as follows:
- By adding numbers, the spectrum (S) increases by 10. This is equal to 368, which can be guessed in 30 seconds.
- By adding special characters as well, the spectrum (S) increases by 32. This is equal to 688, which can be guessed in 1.5 hours
- By adding uppercase, too, the spectrum (S) increases by 26. This is equal to 948, which can be guessed in 20 hours.
All this math proves that an 8-character password is no longer secure. Therefore, to be considered secure, a password should be at least 10 characters long and include all of the above. This math is very important, especially to support the requirements to determine the password policy of your organization (and gain the buy-in from users and executives).
Tip
If you want to check the password strength without having to do all the math, I recommend the following site: https://www.grc.com/haystack.htm
Dictionary attacks
This is similar to a brute-force attack, but instead of guessing the password, it uses a dictionary with the most common passwords.
You can find dictionaries with millions of passwords. In fact, some of them are so big that they can make Notepad crash. So, to make it easier for the attacker, most dictionaries are sorted by topic, region, language, or by source (normally from a password breach).
As mentioned, this attack is different from the attacker's point of view, but the same tips provided earlier work for this type of attack.
If you want to see what dictionaries look like, here you can see many dictionaries sorted by several factors: http://www.md5this.com/tools/wordlists.html.
Test yourself
Take a look at these two passwords and think which one is more secure, and then go to the link above and see the results:
Lol********
C4b-6W@8#5
Creating a secure password
If there has ever been a never-ending debate, it is probably the one about password strength. My grandpa used to say: Avoid talking about religion, politics, and soccer because it will always end in a fight and you will lose many friends. Well, I think that "password strength" conversations should also be included on that list.
I remember being on a board of experts from all around the world discussing very challenging topics and, despite our differences, we were able to agree on all topics but one: passwords!
Some experts believe in pure length (such as using long phrases), others in complexity (they want something unreadable), others want both, but the most controversial topic is around password expiration. There are mainly two parties – the dictatorial and the user friendly.
The dictatorial don't care about the user experience, they just want to create the rules and leave it up to the user to figure out how to comply (even if this means writing the password on a sticky note below the keyboard).
On the other hand, the user-friendly group uses a more empathic approach by analyzing how realistic it would be for users to comply with a given rule without adopting bad practices.
In that context, instead of taking one side or the other, you must make your decisions based on facts (data never lies). Therefore, to create a bulletproof password expiration policy, I recommend that you find a response to the following questions:
- How technical is my audience?
- How educated are they in terms of passwords?
- Can you apply segmentation based on user roles? (Privileged users will change their password every 90 days, while regular users will do this every 180 days).
- Do I have the infrastructure to enforce this policy?
- Can you apply segmentation based on the data/systems accessed/used?
- Do they have the tools and training to create/store/manage complex passwords?
Additionally, there are Three Golden Rules to help you improve password security within your organization:
- Implement password vaults: By default, people don't trust putting all your credentials on an app. In this case, you need to educate users and show them all the benefits of using a password vault (starting with the fact that this is better than having the password on a post-it under your keyboard).
But don't go the hard way by making a policy and forcing everyone to implement it. Instead, lead by example, show the people how much you love using your password vault, how easy it is to use it, and how convenient it is to log on to all your apps with a single click. Brag about how you have a unique bullet proof 80-character password for each of your accounts, yes, a different password for each account. Let them know that this is not just for corporate usage, but for their personal life, show them how confident you are that your boyfriend will never be able to guess your password because you will never have to tape it (never be afraid of shouldering again), just a single click and bam!, you are connected to your account. The only thing you need is a password vault app (there are many free and even open source options) and a master password to unlock it (since you only need to remember one, make sure this one is secure). Remember that passphrases are always a good option.
Once people see how easy this is, they will love it and begin asking for it (so instead of you chasing them to implement it, they will chase you to have it). If you want to reduce costs, you can try KeePass, it has everything you need and is free and open source. Another option is to use LastPass; they have a great version for free, but also offer some extra options that may be useful to your organization for a very low cost.
Tip
To create a passphrase, try using a sentence that you won't forget, such as I remember the day when I met my girlfriend at Walmart, or I would never eat a burger again at Happy Burger.
- Once everyone loves it, create a policy and a system to enforce it: Make sure that a policy is created, approved, and published before applying any enforcement mechanism. Otherwise, you may end up with a lot of complaints and unnecessary support tickets due to password issues.
- Don't be a ruler, be a leader: Instead of defining a crazy password policy that no one understands and everyone hates, create some training or webinars relating to passwords, as well as the dangers and consequences of a data leak caused by a weak password. If time allows, perform some real demonstrations, set a Kali machine with John the reaper, and show how you can crack any 8-character passwords in no time. Remember: A document is better than nothing, audio is better than a document, a video is better than audio, but nothing beats a real-time demonstration. In the beginning, you may think that it is very time-consuming, but based on experience, all the time and effort you invest in face-to-face training and demonstrations is time well invested.
Once people understand the consequences of using a weak password and the advantages associated with your password policies, they won't see them as a pain, but as a tool that can save their job.
Managing passwords at the enterprise level
While the previous pages were intended to help you improve your password management skills, there are still some additional security considerations that you must follow when managing passwords at the enterprise level. Now, let's explore the main threats that you may encounter when managing this kind of environment.
Hash attacks
As mentioned previously, passwords are not stored in plain text (well, at least they shouldn't be), so normally they are stored as hashes. Hashes are normally called one-way hash functions, meaning that they were created to be mathematically impossible to create a reverse function to obtain the plain text based on the hashed value.
This sounds very cool, clever, and secure, but it is NOT! (I think hackers are way cleverer).
To crack them, hackers use something called Rainbow tables. The concept is very simple. Basically, it is a database of hash/plain text combinations that can be used to determine the corresponding text of a given hash and this is possible because the hash value of a word or phrase will always be the same.
Rainbow tables are huge (they may contain billions of combinations), making this kind of attack very dangerous.
Tip
If you want to play around with rainbow tables, you can visit this site where you can download a big collection of them: https://crackstation.net/crackstation-wordlist-password-cracking-dictionary.htm.
However, do not worry! There is a way to defend against Rainbow table attacks; you just need to do what you do when you get a salad….Add Salt and Pepper!
Defensive solution – Using salt and pepper
Despite the funny name of this technique, this is actually a very powerful mechanism for protecting against Rainbow table attacks and it is actually simpler than what you may expect.
The salt
This entails adding randomly generated text to your password before being hashed. This salt is then saved on the same password database to be used for further authentication:
$Salt = random_bytes [$Salt] $Hash = SHA [$password + $Salt]
Why should the salt be random? If the salt is the same, then the attacker will be able to identify users using the same password as seen here:
$Salt = random_bytes [$Salt] $Bob_Psswd = [$password + $Salt] | Hash= 68586044d92547df605b $Jake_Psswd = [$password + $Salt] | Hash= 68586044d92547df605b
But if they use a different (randomly created) salt, the hash will be completely different and therefore an attacker won't be able to determine whether they are the same:
$BobSalt = random_bytes [$Salt] $JakeSalt = random_bytes [$Salt] $Bob_Psswd = [$password + $BobSalt] | Hash = 10db4775dc38f4 $Jake_Psswd = [$password + $JakeSalt] | Hash = dc74116ef9525h
So, as seen in the preceding example, even if Bob and Jake use the same password, the attacker won't be able to determine that because the salt used is different.
The pepper
As mentioned, the hash and the salt are stored in the same database, so if an attacker can access the database, the hash can be compromised even if salted.
To reduce that risk, we can add another string of characters (just like the salt), but this time this value is saved in another location, converting this new string as a secret to the attacker because even if the main database is compromised, the pepper will remain secret:
$Pepper = I.am.the.Pepper $BobSalt = random_bytes [$Salt] $JakeSalt = random_bytes [$Salt] $Bob_Psswd = [$password+$BobSalt+$Pepper] | Hash = h1k477g56 $Jake_Psswd = [$password+$JakeSalt+$Pepper] | Hash = o28l4115h
In the preceding example, we can see how the password is composed on the basis of three variables (the password, the salt, and the pepper), which increases the complexity exponentially to crack it.
In terms of the implementation, it is up to you if you want the salt to be added in front of the password or at the end of the password. The important thing is that it is added before the hash is created. As my math teacher used to say: the order of the factors does not alter the product.
Also, it could be difficult to implement a dynamic salt on legacy systems. In those cases, I strongly recommend the use of salt and pepper to increase the security of the system.
Salt efficiency is about randomness, pepper is about secrecy.
You can use the same pepper for all passwords on the same system, but my suggestion to you is to use a different pepper for each system (if one is compromised, it will not compromise all your systems).
Bonus track
Let me share with you the latest research associated with trying to resolve the password problems (hardware and software):
Enhanced password authentication
This is a super interesting system that I developed with Rhonda Childress, Deputy CISO at Kyndryl, about a system that leverages a USB vulnerability and transforms it into a clever solution to the password problem. Here is the link to the full patent pending disclosure: https://patents.google.com/patent/US20200092282A1/en.
Wireless injection of passwords
This idea was part of some research conducted with my friend and security expert John Feezell, in which we wanted to take password vaults to another level by enabling a true plug-and-play solution to wireless inject passwords from a password vault. The beauty of this system is that it does not require the installation of any special driver and firmware and yet can still work on any OS. You can check the details at the following link: https://patents.google.com/patent/US20190163893A1/en.
Keyboard injection of passwords
This is an improved version of the previous idea in which we added another layer of security and leverage the currently connected keyboard as the input mechanism to inject the password as normal keystrokes: https://patents.google.com/patent/US20200074069A1/en.
We covered a lot of good information about the main risks related to passwords and how to address them from the point of view of the users and the infrastructure. Now is the time to jump to the next level and see how we can create the best defensive security strategy based on interconnected layers of systems, methods, and techniques.
