Secure your Accounts (3 Part Series)
I will cover and answer your questions about everything that I am talking about in this post on Twitch this Thursday 2nd April at 9:10pm (UTC+1).
Feel free to come and say hello, if that is of any interest to you or if reading that article brought some questions.
You can watch it here, if you missed it.
Login and Password (aka Credentials) are the most widely used method to connect to a service on the Internet. You are using it all the time.
And very often you can see, on the news, that a new website has encountered a leak and that their password database is available on the Internet.
We can think of a lot of services whose password databases leaked. LinkedIn in 2012, Yahoo in 2014 with 3 billions user accounts compromised and more recently, Equifax in 2017 with 140 millions user accounts compromised.
That is why you must have a different password per website.
Unfortunately, it is impossible for a human to remember a single, complicated enough password for every website he is using nowadays. Any individual has basically at least a hundred different services he connecting to on a weekly basis. It is just not possible to remember that many passwords if you want to have complicated enough passwords.
That's where Password Managers can come to a help. They are good at making complicated password and remember them for you. To keep all of them secure, you just have to have a single complicated password to remember. And this, I am sure you can remember. Especially if you are typing it multiple times on a daily basis.
Let's have a look at some great Password Managers service.
A Password Manager is a software that helps you handle the complexity of passwords to the numerous services that you are registered on.
If you want to see a hands-on of KeepassXC and password, you're welcome on the Twitch live session this Thursday April 2nd at 9:10pm (UTC+1). 📺
Here is a presentation about registering and logging on a service using credentials.
Hashing a string is using a mathematical function that changes a string to another unique string.
The result string is a fixed size. It doesn't matter what is the size of the source string, the result is always to be the same number of characters.
Hashing is a non reversible function. That means that it is a one way function.
You cannot find what was the source string from the Hash value.
Let's see how we can hash a string.
You can use the following command for the SHA1 algorithm :
echo -n "This a test sentence" | shasum 8d7e3ef52c11ce610896f32183038edcc5caa9ac => 40 characters
And this command for the SHA256 algorithm :
echo -n "This a test sentence" | shasum -a 256 419e405bb7fea7f572f8fbf833e3a37fe13c532e85c952d9649965752ddb0c88 => 64 characters
There are many hashing algorithm. Some of them are known as vulnerable.
MD5 and Sha1 algorithm are known as vulnerable and should not be used.
Basically what's inside a password database are the Hash values of the plaintext password, if the developer do their work and did not store plaintext password.
If the software team is using SALT on the passwords, then you have to store the SALT along the user name and the Hash value of the concatenated password and SALT.
So, do we care if a password database leaks on the internet?
Let's see about it.
Here is an exemple of a Rainbow Table. It is basically plain text passwords and their corresponding hash values.
Let's consider two services, Service1 and Service2.
If the Service1's password database leaks, and I have the "da4b9237bacccdf19c0760cab7aec4a8359010b0" value in it as the password, then I know that the plain text value of the password is "2".
It is then very easy to log in the Service1 with the "2" password.
And 💥, I'm in. 🔓
This is a Rainbow Tables attack. 🌈
Another basic attack against passwords is Brute Force attack.
A Brute Fore attack consists of trying every single string possibility.
You can use a very simple created list, like the following one :
a aa ab ac ... b ba bb ...
or much more advanced wordslist as Rockyou which is a widely used wordslist :
123456 12345 123456789 password iloveyou princess 1234567 rockyou 12345678 ...
Some softwares are doing Brute Force attacks very efficiently. Hydra can perform Brute Force attacks very efficiently.
A long and chaotic enough password makes it impossible for Brute Force software in a acceptable time for an attacker regarding the actuel processing power.
Nevertheless, not every users are using strong enough passwords. That's why, one must always set up an anti Brute Force mecanism on the password Login UI.
A protection is to allow 3 login tries and then you have to wait for one minute to try again.
It is very effective to make any brute force software useless against it.
To stay protected from Rainbow Tables attacks, sercices are using SALT on the password.
Salting a password consist of adding a random string at the end of the password and hashing it before storing it in the database along the user name and SALT.
The Salt is as long and chaotic as we want and is store alongside the password and user name in the database.
It protects users from similar passwords.
Indeed if two users have the same password, using the Salt will make the result of the hash function different for the users. So if the hashed values of the passwords leak, two users that have the same plaintext password will not have the same hashed value in the database.
Let's try it with an example again.
The users are both using2 as their password to login to the service.
The service is salting and hashing passwords before store it in the database.
It gives these values in the service's database.
User Name | PlainText Password | SALT | Salted Hashed Password (SHA256)
-- | -- | -- | --
user1 | 2 | MEVBbZ72YsqKMKed | 5ab55dc80af1d312d518cbaf30152cb448ad52e5fdcea96e097dea72f2eb23fc
user1 | 2 | c8kkSqF3rdohAvbL | 5678431c0d6c94bce312e215b6514fabee6542d7b264ded21a65753e814fb677
The PlainText password are not stored in the database, they are just here for explanation purpose.
As you can see, the hashed value of the plain text passwords are different, even if both users have the same plain text password.
That means that if user1's password leaked somewhere else and was in a Rainbow Table, we cannot deduce user1 or user2 password as the hash value we are going to compare is different.
"d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35" from the Rainbow Table is different from "5ab55dc80af1d312d518cbaf30152cb448ad52e5fdcea96e097dea72f2eb23fc" (user1) and "5678431c0d6c94bce312e215b6514fabee6542d7b264ded21a65753e814fb677" (user2).
So users, on that service, are protected from Rainbow Table attacks.
To get the hashed result of a string, you can use the terminal and try it all by yourself.
The hash for user 2 plain text password, using SHA 256 algorithm, is :
echo -n "2" | shasum -a 256 d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35
If we are using "MEVBbZ72YsqKMKed" SALT (the one used for user1)
The password that we are hashing is now "2MEVBbZ72YsqKMKed"
echo -n "2MEVBbZ72YsqKMKed" | shasum -a 256 5ab55dc80af1d312d518cbaf30152cb448ad52e5fdcea96e097dea72f2eb23fc
- Use a Password Manager
- Use a complicated encough master password
- Generate passwords from the tool that are at least 12 characters long
- Never store passwords in plain text in a database
- Stored passwords must be hashed
- Use SALT to avoid Rainbow Table Attacks
- You can even set up Pepper to enhance it
- Set up a delay after some failed attempts to avoid Brute Force attacks