The password strength table.

I recently saw a tweet from the Vosges Gendarmerie about the strength of passwords containing this picture:

Although very interesting and giving a good idea of how complex a password should be, this information, without context or explanation, is a bit misleading in giving the impression that a password of, say 12 characters, is sufficient.

Unfortunately it's much more complex (as it often is 😉 ).

If you attack an account on its password, there are two categories of attacks:

• "Offline" attacks, where you have something to try to break (or recover) the password at home, on your infrastructure, without interaction with the application, site, service... ;
• Online attacks, where you try to find the password by attacking an online service, a web application, an account on the network... This is where the main concern of the table comes from, it only concerns the "offline" mode.

This has already been covered by the presentation I gave at OSSIR in May 2019 as well as the blog post "Breaking password digests... without violence", but here are some reminders and additions about these attacks.

To perform an "Offline" attack, you need something that allows you to retrieve the user's password. In general, this something is a hash of the password. It is usually a non-reversible transformation.

Sometimes it is performed on the password, together with a salt. It is an additional element, unique for the password, and allowing to prevent any pre-computation attack (the famous Rainbow Table) to find the password, from the condensate.

It can also be an intermediate pre-computation as for WPA2 with PMKID, a signature... but to make it simple, let's talk about condensates, because the breaking techniques are finally similar.

These condensates can come from several sources:

• Hacking a service or website and stealing its condensates database (if the passwords are in clear text, then it's already won 😉 ) ;
• Hacking of "anything" containing password digests (ntds.dit Active Directory database, /etc/shadow file, SAM database, MS-Cache, NTLM Answer Challenges...) ;
• Network interception, waves...
• Specific techniques allowing to ask to recover condensates (Kerberoasting, known cleartext attack...) ...

There are two main families :

• Exhaustive attacks consisting in testing all possible passwords (of which I consider Rainbow Table to be a part, with a nice shortcut but it's not the topic here and yes, I'm going to say that very often, sorry 😄) ;
• Dictionary attacks, based on a predefined list of passwords, which can be completed, modified or derived with rule sets.

This is the simplest and often the longest technique, because it consists in taking all the possible passwords, generating the condensate with the same algorithm as the one of the condensate we are trying to "break" and seeing if the resulting condensates are the same (which means that the password is the right one, with the rather unlikely collisions on passwords).

And this is where the above table comes in with several remarks:

• Whether the password contains a trivial word or random characters, it is almost the same, except if you know in advance the types of characters used (lower case, upper case, numbers, special characters). So "cuckoo" will in fact have the same complexity as "$*2We@". Afterwards, it is quite possible to first search for passwords with simple characters, then to increase the power with numbers and special characters;
• The breaking time will depend on the attacker's computational capabilities, mostly based on computers with powerful graphics cards. Considering the classical characters of the alphabet, we have for each password length the following number of possibilities:

Computation time on my laptop for the SHA-2 256 bits condensation algorithm, used by many websites :

Computing time on our dedicated breaking machine for the 256-bit SHA-2 condensate algorithm:

Computation time on my laptop for the NTLM condensation algorithm, used by Microsoft to store user passwords:

Computation time on our dedicated breaking machine for the NTLM condensate algorithm:

Overall, the results are quite similar between my last picture and the one mentioned in the introduction. Moreover, I kept the philosophy of the colors but between immediate and less than an hour, for me there is no difference.

You also have these reference values from RandoriSec which are quite accurate (on another condensate algorithm):

Clever exhaustive attacks

As it is complicated to find long passwords, there are several techniques that I have already detailed (cf. "Breaking password condensates... without violence") with the use of masks, i.e. limiting the space of possibilities (types of characters) for certain positions, such as, for example, all words (existing or not) capitalized of a certain length and ending with two digits (e.g.: Sunday20! )

Dictionary attacks

To further reduce the range of possibilities, the use of dictionaries completed with derivation rules remains very effective, mainly because many people use common words for their passwords, completed with special but classic characters and always positioned in the same place.

Moreover, following the numerous data leaks that have taken place and the diffusion of their condensed databases or even passwords, most attackers have dictionaries containing many real passwords, improving the breaking, here again, I refer you to the various articles cited.

This is a completely different subject and the table in the introduction may be confusing.

When we talk about "online" attack it means that we try passwords directly on the application, the website, the service... The attacker is therefore dependent on several limits:

• The response time of the online service, which can be partially circumvented by parallelizing the attempts;
• The limits imposed by the online service (number of attempts in a given period of time), which can be partially circumvented by parallelizing on different attack sources (in general, these limits are per IP address);
• Blocking the account after a number of unsuccessful authentication attempts. It is therefore not possible to test 40 million passwords in a few seconds. The table in the introduction is totally irrelevant.

Here are the different attacks that can be performed.

Exhaustive attacks

It is simply a matter of testing all possible passwords but rarely possible because of the limits mentioned above. With a response time of 300ms (which is already good) testing just 1,000 passwords already takes 5 minutes without parallelizing and if there is no limit.

Dictionary attacks

Here again, as for the "offline" attacks, it is a question of testing the contents of dictionaries of passwords, with or without derivation rules, but here again, this attack is dependent on the limits mentioned above.

Exhaustive attack on test services

Sometimes, test services, development services... do not have some of the limitations described above and therefore allow to test a large number of passwords quickly. This was the case in 2016 for the "beta.facebook.com" platform.

Password Reuse

This is the most classic technique: I find a data leak on site A and try the password associated with your account on site B. If you used the same password, too bad 😉.

Password Spraying (which I've sometimes seen called Credential Stuffing).

This is mainly about testing few passwords but on a large number of users, so as not to be dependent on the limitations mentioned above. Several tools allow to automate this attack like :

• SentryMBA
• OpenBullet (integration with Selenium to reproduce the behavior of a human behind his browser)
• Storm
• Snipr (allows to test combinations of identifiers and passwords on mail servers like IMAP, SMTP ...)
• Private Keeper
• Woxy

Each tool has its advantages and disadvantages. They require an account list, passwords and a specific configuration for the targeted site:

• Form fields to fill in;
• The action to be taken in case of success (such as resetting the password);
• A list of proxies to avoid launching all your attempts from the same source of attack. For individuals, these attacks are less and less effective, but for companies, test "CompanyName2020!" on all the users of a company and you will have great chances to have several successes 👍.

Hidden channels and oracles

I won't go into detail about these attacks which are often related to problems with the implementation of cryptography which is not done in constant time, but there are other techniques to get information about the password, leading in some cases to the ability to retrieve it.

Session tokens

I'm also not going to detail here all the techniques of session token prediction, token decryption... that's not the topic here 😉.

Here are some comments acting as conclusions, mostly related to the responses on the Vosges gendarmerie tweets.

Going back to the gendarmerie board and my introductory example, if a 12-character password is in a dictionary, then it's easy to break.

Just as a 9-character password can be difficult to break, if it is really complex (with a high entropy). So everything will depend on the information available to the attacker and the context.

No, not if this password is in a dictionary and thanks for the idea, I'm adding it to my own dictionaries (at least the "CM#Apollon" because the year will be added by my derivation rules)

Yes yes yes!

Re-yes yes yes!

No, an attacker won't be able to guess your password and authenticate for you on Axa or Facebook in 2 minutes, even if your password is 8 lowercase and uppercase (unless he already has your password).

Here is Mitnick's video showing how to break a complex password in less than a minute: https://www.youtube.com/watch?v=46ODE0bot1I&feature=youtu.be

It generates a password that looks strong but in reality it is not, then it uses the hashcat tool with a dictionary (not provided) and derivation rules (not provided).

This password is written in "leet speak", that is to say by replacing some characters by numbers (cf. wikipedia), a known technique and the hashcat tool embeds adapted derivation rules allowing to transform, for example, "password" in "p4ssw0rd". Then, as the dictionary and the derivation rules are not provided, it is impossible to know if this password (at least partially) is not already in its dictionary. The same is true for the derivation rules which are perhaps specifically adapted to this demonstration 😉.

And no, using the same password with the site name is not a good idea. If an attacker looks at your case manually, it will be obvious for him to find your other passwords.

And no, the tools mentioned (here Cellebrite) mainly use vulnerabilities (or protection bypass techniques) to get into the devices and most often require physical access (I'm not going to talk about iCloud attack tools like Elcomsoft's here).

The best recommendation is to have a password vault (Keepass, Bitwarden, Dashlane...) with complex (randomly generated) and unique passwords per site/service, combined with a strong two-factor authentication.