Confused about using a password that "would take centuries to break"

Question

I am talking about this password - 23##24$$25%%26 and the similar ones consisting of special characters appearing in a pattern, which the users these days use a lot.

At work (finance company), I was creating a list of bad passwords that users should not be allowed to choose, involving certain cycles or pattern, and the above kind exhibit that trait of containing consecutive numbers sandwiching special characters (repeated certain times, here twice).

Just out of curiosity, I checked this on a very well known website (on its login page), and it stated that this would take centuries to break.

Some more examples in the list which would take years to break, but are highly vulnerable:

1!2@3#4$5%6^ 2@3#4$5%6^7& a!b@c#d$e%f^

Now, I stand confused with the list, should I mark these particular kinds of passwords as vulnerable and disallow the users going for them, even if they take a very long time to break?

Note 1 - We are considering these vulnerable as many users (and, hence, multiple similar passwords) are following this trend to remember things easily.
Note 2 - We are confused because the security guys are all about increasing the entropy, what they are ignoring is an increased orderliness of similar hashes in the database
There arose a friction between guys as to where we draw a line, defining which password be allowed or disallowed.

Edits:

• This website I am talking about, but won't name, on which I tested the password is pretty much known to every ethical/unethical hacker, almost every user here on Stack Exchange and many big/small companies (as they use its services).

• We do not store passwords in plain text. We use a nice, not home-brewed, hashing algorithm.
  An incident led us to review our password policies, and we created a separate database db-2 on a different machine, wherein we stored simply_hashed_newly_created user's password (no salt, nothing, just hashed_password) without storing who_created, when_created details. We did this for short period only. Any password change too went into this database. While, in our original database db-1 sat secure_salted_passwords.
  We kept creating a list L of hashed vulnerable passwords as well, following a pattern, and we were left amused when we matched L & db-2 - we saw multiple groups of similar passwords, with certain patterns. L and db-2 were later erased from the systems.

• db-2 was kept on a highly secure machine and was safe, won't disclose the exact details here. We are aware that even air-gaps or electric-sockets aren't secure. Both db-2 and L were destroyed.

• Worry not about passwords posted here, as we have already conducted our small experiment, and all those specific set of users have been made to reset their passwords (of course, a new password different from the old one). That's the reason, I came here posting few samples.
  And, I have commented here earlier too, that I posted a sample of passwords from the generator's logic which created a very huge list of hashed passwords, which may or may not be in db-2. Again, since all those users have a new password, so no worries, everything is safe and secure.

• Since I know the generator's working, I tested few password-samples on a website, and we got confused over which ones to be allowed or disallowed, over what criteria.

Thanks a lot for your answers, accept my gratitude. Based on the answers, for the time being, we have postponed any kind of restriction to be put over password's choice.

Answer 1

The online calculators are basing their results on a particular set of assumptions, ones that might not apply in any one case. There is no basis for trusting the calculators to provide any insight into how an attacker might choose to break the password.

For instance, if I know that you use a pattern, and what that pattern is, then I would adjust my bruteforcing to align with the pattern. There is no way for an online calculator to account for that. There are other similar factors to take into account. "Entropy" is all about ensuring as much randomness as possible. A set pattern has much-reduced randomness, regardless of the characters used.

So, yes, do ban such obvious patterns, if that meets your goal.

I do have concerns about your method of banning these passwords, though. You might be fighting the wrong battle.

Answer 2

Just out of curiosity, I checked this on a very well known website(on its login page) and it stated that this would take centuries to break.

Such websites cannot be taken as gospel. Many are worthless, and even for the good ones the results must be carefully interpreted. First of all, as a general rule, a strength checker can conclusively tell you that a password is weak but cannot really prove to you that a password is strong—the password that it can't find fault in could well fall to some attack that the meter doesn't model. For some extreme examples, this Ars Technica article describes successful cracking attacks on some otherwise impressively long passphrases:

Almost immediately, a flood of once-stubborn passwords revealed themselves. They included: "Am i ever gonna see your face again?" (36 characters), "in the beginning was the word" (29 characters), "from genesis to revelations" (26), "I cant remember anything" (24), "thereisnofatebutwhatwemake" (26), "givemelibertyorgivemedeath" (26), and "eastofthesunwestofthemoon" (25).

The other thing is that just because one meter told you that it judges the password strong doesn't mean that all such meters do. For example, the zxcvbn checker, which is one of the best, thinks this is breakable in 3 hours by an offline attack if the password hashing is weak:

password:              23##24$$25%%26
guesses_log10:         14
score:                 4 / 4
function runtime (ms): 3
guess times:
100 / hour:            centuries  (throttled online attack)
10  / second:          centuries  (unthrottled online attack)
10k / second:          centuries  (offline attack, slow hash, many cores)
10B / second:          3 hours    (offline attack, fast hash, many cores)

match sequence:
'23##24$$25%%26'
pattern:               bruteforce
guesses_log10:         14

It estimates 2 minutes for 1!2@3#4$5%6^, 2@3#4$5%6^7& and a!b@c#d$e%f^ with a 10B/second attack (3 years at 10k/second), so those it thinks are even worse. (Though it does score all of them 4/4. The meter is recommending that you actually accept any of these passwords, because it estimates they're reasonably likely to resist attacks if your application has implemented slow password hashing. But its analysis actually proves they're weak to a specific attack that you should mitigate.)

Note that zxcvbn models attacks based only on general knowledge of how most users pick passwords—it doesn't have any specific knowledge about how your organization's password policies or practices might allow a specialized attack to somebody who learns them. And always remember, the tool can tell you that a password is weak, but not that it is strong—zxcvbn estimates centuries to crack Am i ever gonna see your face again?, which from the Ars article we know has actually been cracked in real life.

Now, I stand confused with the list, should I mark these particular kinds of passwords as vulnerable and disallow the users going for them, even if they take a very long time to break?

Your instinct that these passwords should be banned actually turns out to have some justification, as shown by the zxcvbn results. The problem is that you're unlikely to succeed in compiling a finite list of passwords that are similarly vulnerable, nor of patterns that an attacker might successfully exploit. For example, to catch all the passwords that zxcvbn thinks are as vulnerable as the latter three, you'd need a list with 1.2 trillion entries (10B passwords/second × 2 minutes). Not practical. Even if you try to condense things down to a small list of patterns to reject, I wouldn't count on successfully outthinking your attackers.

One thing you should definitely do is use strong password hashing, with the bcrypt or Argon2 password hash functions. This is what the zxcvbn results above call "slow hash," and it likely makes your password entries much harder to break. (But again, remember a strength checker can tell you that some password is definitely unsafe, but not that it's safe.)

Things you should consider in addition:

• Use a small list (thousands) of passwords that are known to be very common, and forbid those. Such lists can be readily found online.
• Use Troy Hunt's 500M+ breached password list, which also has an online API. (Make sure you read the material on k-anonymity so you don't actually send passwords to the API!)
• Use a smart strength meter library like zxcvbn, which is a much more sophisticated alternative to pattern detection like what you're contemplating.
• Implement a second authentication factor, so that passwords are not your only line of defense.

Answer 3

Guessability of passwords means knowing something about the kind of passwords people might choose. We all know "Password" is guessable because it's an English word. But to know that you need to either know English, or have a concept of how English or other related languages spell words. An alien from somewhere in the vicinity of Betelgeuse that's never been exposed to English or another human language isn't going to know that "Password" is easily guessable. In other words, patterns are somewhat subjective, which (beyond a certain level) makes them terribly difficult to predict in advance.

Similarly, for some of the passwords on your list it isn't immediately apparent what the pattern is. 1!2@3#4$5%6^ looks somewhat "random" at first glance, but you'll quickly notice that on a QWERTY keyboard, it's simply 1-6, and alternating every other character with the shift key.

In addition, if someone showed you the password CPE1704TKS you also might think it's a good password. It has 10 characters of letters and numbers, there's no determinable repeatable pattern to it, and it's not a word in any human language. You'd be wrong though, and this isn't a great password because it's the password used to launch the nuclear missiles at the end of the movie Wargames.

For this reason, using calculations of "crackability" (based on length and character selection) from a random website are largely bogus. Furthermore they depend on someone obtaining the password hashes, which itself is a major security compromise. They're doubly bogus because they imply you know how quickly a hash takes. Hashing speeds vary by many orders of magnitude depending on which algorithm you've chosen. So take "crackability" scores with a grain of salt. Most attacks on passwords these days use common passwords, or reused passwords not pilfered password hashes.

Really, this comes down to simply maintaining a list of "bad passwords" that other people have found over the years that have some sort of special meaning. My guess is that's where the security guys are coming from.

Answer 4

It is impossible to prove that a given password is hard to crack.

What you mean by the (correct) statement that these “are highly vulnerable” is that there exists an easier guessable algorithm for generating them, namely “hit the number row of a QWERTY keyboard in such and such simple pattern”. This happens to be an algorithm that's easy to recognise for a human who spends all day pressing her fingers on such a keyboard, but patterns on such a keyboard are actually rather “non-obvious to a computer”, because in fact most computer programs don't care at all about the physical layout of the keys^†.

I could equally well give an example like YWJjZGVmZ2hpamts, which you might think is a reasonably safe password, but you would actually be wrong because it happens to be the Base64 encoding of the string abcdefghijkl, and that might seem totally obvious to an AI for which a string is foremostly a bit pattern.

The notion of how simple a given bit of information can be expressed is called Kolmogorov complexity. Despite the simple definition, this is actually a very tricky concept: it depends highly on the language in which you want to express everything, and it is uncomputable. Really the best you could do is evaluate all possible short programs in an expressive programming language with a big standard library, but if that doesn't succeed^‡ it does by no means guarantee that there is no low-entropy way to calculate the password in another language which includes one crucial standard function. If you didn't know about the QWERTY layout, you might also think that asdfqwerzxcv is safe, despite the complete obviousness when you do know it.

The upshot: if you do find any low-entropy representation of a given password, then yes, forbid it. But never take anybody's (including any program's) assertion at face value that a given password is secure if they don't know how the password was actually generated. If you want to guarantee truely uncrackable passwords, the only way is to make sure that they come out of a quantum-mechanical physical random process.

---

^†_{Any program concerned with password cracking should know keyboard layouts though, because it's well-known that humans tend to resort to such patterns. Also, 23##24$$25%%26 is pretty easy even without knowing the keyboard layout, because the number row is almost ordered in ASCII. So, these websites are really doing a terrible job here.}

^‡_{That's even disregarding run-time problems. What you're doing here is just as hard as brute-forcing an unknown password.}

Answer 5

A password like "12345678" could be considered random, if you want. If you use a generator of random passwords, the probability of generating "12345678" is the same as that of "4h2Ud8yG" (only considering alphanumeric passwords). And "12345678" can be as hard to break as "4h2Ud8yG", if you bruteforce it randomly in the range from "00000000" to "ZZZZZZZZ". But the truth is passwords shouldn't just be random, they should look random too. Why? Because attackers will often use bruteforce based on dictionaries or patterns, so passwords that aren't based on words or patterns are more secure. Also if words and patterns are used to make the password easier to remember, then chances are all the other passwords used by the same person will be easier to remember in the same way. So if an attacker steals one of your passwords and it looks like "John75", they are likely to break the majority of your passwords by bruteforcing patterns such as "name + number", "word + number", or some variations. But if the attacker steals one of your password and it looks random like "4h2Ud8yG", then they won't be able to extract any information from it.

So you are right when you say those passwords you have are not really secure. They don't even have all the entropy you think they have! And this is because password entropy is based on the way a password looks like, or the way a password is created. A password like " 1!2@3#4$5%6^", if you think of it like "number followed by symbol, six times", you would have (10x10)^6 = 10^12 possibilities. Which is less than the possibilities for a simple 8-character password made of lowercase letters and numbers: 36^8 = 2.8 x 10^12 possibilities. But if you think of that example password like "number followed by symbol on the same key, starting from 1 in ascending order, six times", then the total possibilities are... only one!

Answer 6

First off, those password stregth indicators are guidelines, not absolute truth.

Secondly, how secure a password is, or how long it would take to crack depends on a few factors. To understand this better, it's important to understand how passwords 'break' in the first place.

There are 3 common attacks on passwords:

1. Attackers try to logon to a service by guessing the password
2. Attackers found the same username/password combination in a separate breach and are now using it against an un-breached service (credential stuffing)
3. Attackers obtained the database dump of a service, and have the password hash. They're now brute-forcing the hashes to determine the plaintext password.

To prevent attackers straight up guessing passwords, we enforce some sort of 'entropy rule' AND we rate-limit logon attempts. This way the attackers can't brute-force your service directly.

To prevent Credential stuffing is a more difficult.Regardless of how strong you force passwords to be, it'll be of little help if the user had the same password on a separate breached system -- and that system stored it in plaintext!

Some companies (notably Amazon, LinkedIn and OpenTable) are even accessing data breaches and alerting their customers -- even though those breaches are outside said companies. This helps protect against credential stuffing (somewhat!), but might be a tad-bit too far.

Finally, there's the typical brute-forcing a password-hash. This is where an attacker has somehow got hold of users password hashes and is now trying to guess the plaintext from the hashes. Here's where we commonly hear the it'll take centuries to break trope.

Typically the attacker will use a tool like ocl-hashcat in combination with a wordlist of common password (like RockYou or Top1000 passwords, etc) to guess the plaintext. Attackers might also brute-force every combination of letters, numbers and special characters, but this isn't common, because it's less efficient than a wordlist.

The slow down the attack, we usually rely on :

• Using a Strong hash function (Bcrypt instead of MD5)
• Salting individual passwords (to force attackers to brute force one by one)
• Preventing users from using weak passwords
• Preventing users from using passwords in previous data breaches (because wordlist are made up of previously breached passwords).

For the last 2, NIST recommend the following:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

Obviously, services should force a password reset once a breach is discovered on their service.

In short, don't be confused about taking centuries to break nonsense. Apply a reasonable set of practices around protecting passwords and you should be good, do not rely entirely on these password strength indicators to determine your security posture. This NIST link is a good place to start.

Answer 7

Most of the online advise on passwords is, to put it friendly, without any solid foundation whatsoever. This goes especially for so-called password complexity, which is based on a myth from the 80s and fortunately - after the original author at NIST admitted it last year - on its way out.

You can not make an estimate of password strength without understanding what you threats actually are. All of the trivial online calculators are nonsense as they just do some math without considering what you are trying to protect against.

Your threat could be brute-forcing. In such case, the first thing to do is to not allow brute-force attacks. If someone enters a wrong password one hundred times and you're not locking him out, you are doing something wrong that has nothing to do with password strength. The second thing to do is length > complexity (put that into Google, great article).

If your threat is a dictionary attack on your password hashes, the first thing to do is to protect your hashes properly. The second is to properly salt and hash with a proper hash function (bcrypt, scrypt, etc. - not MD5 or SHA1). The third is to not allow simple dictionary words and permutations. Use the same logic that the crackers use, some of them are publicly available.

If your threat is shoulder-surfing or post-it stickers, you want to avoid the nonsensical complexity enforcement, and make sure your users can actually remember their passwords, and type them quickly. Again, length > complexity. Make the minimum length 12 characters, but allow compound words.

And so on...

In short: Consider your threats, don't trust trivial math estimates.

Answer 8

Just out of curiosity, I checked this on a very well known website (on its login page), and it stated that this would take centuries to break.

Such claims are always highly dubious.

The fundamental problem is that to calculate how long it would take an attacker to break a password you need a model of the attacker.

An idealised attacker would try passwords in order from most likely to least likely. Of course a real attacker doesn't know how likely any given password is so they have to guess, they will typically combine some sort of dictionary (which if the attacker is somewhat competant will contain a lot more than just regular english words) with a bunch of generation rules.

The problem is that the models of attackers used by password strength meters are often way behind the actual attackers in the size of their dictionaries and the complexity of their rules.

---

The fundamental problem with password restrictions is that whatever restriction you make users will often do the bare minimum to get their password to pass.

Now this can add some entropy, there is normally more than one bare minimum way to mutate a password so it passes the rules, but the entropy added is much smaller than a naive analysis may suggest. For example if you force users to add a number to their password a disproportionate number of them are likely to choose 1.

Answer 9

You are likely confused because of assuming that it is possible to define password vulnerability a priori. Instead, it highly depends on which pattern an actual attacker would try first. Opportunistic attacker would probably try a dictionary or lists of leaked passwords first. But by putting in even a moderate amount of effort, they can get pretty precise. This is a reason why it is a losing battle to enforce guidelines on passwords. Most guidelines promote users to follow certain minimal requirements when choosing their passwords. This can aid brute-forcing them. For example,

• a minimum password length of X characters allows an attacker to avoid trying out all passwords shorter than X and instead focus on passwords of length X, X+1, or X+2 by assuming that many users only fulfill the minimum length requirement.

• Enforcing a pattern like "lowercase, uppercase, numbers and special characters", an attacker can assume that there are users who derive their password using exactly this pattern.

• It would be possible to give them feedback whether their password was a leaked password, but then there is the risks that they would just end up modifying it until it passes. Again, this is a hint for attackers on how to direct their brute-forcing.

• Maximum length is a pretty obvious one. In the best case, a length reduces the benefit of using password managers. In the worst case, they can hint to the underlying technological limitations of the login system. Also, they place an upper bound on the worst-case effort an attacker has to expend.

Answer 10

To determine how hard a password is to crack, you have to know its entropy, which obviously these sites can't know. They make their best guess and then return that as the result.

In order to correctly calculate a password's entropy, you have to assume that the attacker knows as much about how the password was created as the creator did. If the creator always include one of two 10-letter words, then the attacker has to know both that one of those words will be present and what they are.

From this you can see that your pattern is very low entropy (no more than 7 bits). But since the websites don't know that, they rate it as much higher. If you want a good password, you have to have randomness. How to get a user to accept and include randomness into the password is problem. Better to try to figure out how to get someone else to do the password or password equivalent.