4

OWASP recommends this practice and so do some other companies. I think it makes sense at first glance but if you think about it, it actually limits entropy instead of increasing it. How many combinations would be reduce with this rule? I calculated their minimum entropy (10 characters, all 4 types) to be 3e19. Not having characters would limit it quite a bit I would imagine. I don't know how much but I would bet there would be a lot using the birthday paradox as guidance. If someone can calculate that for me and show me the steps, that would be greatly appreciated.

My point is that it would limit it regardless. So what's the benefit? Is there a gain elsewhere, perhaps in the password cracking methodology? As far as I can tell, there isn't much there that I can think of. Can anyone explain why it's benefits outweigh the negatives or perhaps maybe it is just a bad rule and why OWASP and others think like this.

  • Commonly used passwords don't tend to exhibit this unless they're entirely numeric, e.g.: "1111111" or "88888888". Those would be eliminated by other sensible password restrictions anyway. You can find lots of research about commonly used passwords: lorrie.cranor.org/blog/2014/12/19/… – David Feb 27 '17 at 5:28
  • The most obvious result of this rule is that it stops people using "password" as their password. – Simon B Mar 16 '18 at 22:45
4

The link you shared says:

not more than 2 identical characters in a row (e.g., 111 not allowed)

so your limit would apply on 3 characters in a row.

Remember, any limitation enforcing a certain rule reduces the absolute search space for a password. For example, requiring four different types of characters removes the space for all-lower/all-upper/all-digits/all-special character passwords.

The hope with any such restrictions (3 consecutive identical characters / 3 consecutive digits / 3 consecutive digits plus a special character / 3 consecutive QWERTY keys ...) is to reduce the likelihood of users choosing a weak password (one that is more likely to have been already "discovered" and added to a rainbow table).

The benefit may not be apparent if you think of password-cracking as "dumb brute force", but may be clearer if you look at the proportions of cracked passwords from a large dataset that display these weak characteristics.

  • In 2017 I feel that removing all restrictions and instead using Scrypt with a salt is sufficient. – Awn Feb 26 '17 at 10:00
  • 2
    @Eclipse Scrypt and salt doesn't protect a user who has password as their password, it will still be cracked first, even if the attackers now have to try password for each user in the database. It may be time to drop composition restrictions, but you should still keep length restrictions and perhaps add a "not among 100 most commonly cracked passwords"-restriction. – Thorbear Feb 26 '17 at 19:54
  • A minimum length and not a common password seems reasonable. Maybe an entropy calculator if you're really worried. – Awn Feb 27 '17 at 5:07
  • What makes it harder to crack passwords if there are none that have 3 characters in a row? Is there a rule that relied on that behaviour? – Geoff Lee Mar 24 '17 at 4:12
  • In bulk, it might even be easier for an attacker because of this policy. If an adversary grabs the hashed passwords of your company and they know about your 3 character policy, they can remove a large number of entries from their dictionary, focusing their search. However, without the policy, your users could individually choose weak passwords which are easy to crack. – Jedi Mar 24 '17 at 12:40
2

Crackstations "small" password list contains about 64 million passwords. I grep'ed for series of more than two identical characters in a row and found about 1.2 million matches*. This means that less than 2% of all passwords in this list contain more than two consecutive characters.

From these numbers, I'd assume that using many identical characters in a row is not a widespread practice and you therefore need not enforce any precautions against it.


*Please note that a password "aaaa111" would be counted twice.

  • I'm curious: How do I grep for three identical characters? – Out of Band Feb 26 '17 at 20:22
  • I found the answer on stackoverflow and adapted it: stackoverflow.com/questions/14084192/… – Lukas Feb 26 '17 at 21:29
  • Depending on the average length, 2% does seem to be way more than than the expected probability of 3 consecutive identical characters in a 8 character password. – Jedi Feb 26 '17 at 23:22
  • Secondly, you capture distinct passwords, but the frequency of usage of these "weak passwords" would (intuitively, to me) be higher than a truly random password (i.e. more people would use aaaa1111 than *(x9Na&*). Considering how these cracking attempts are sorted (by expectations of usage), an attacker is more likely to try aaaa1111 than *(x9Na&* – Jedi Feb 26 '17 at 23:24
  • Great find, thanks for doing this. This concerns me because it seems like OWASP has completely made this up. If there aren't that many words that have it, why warn against it? They just made it easier for password crackers by limiting the number of words they need to try. – Geoff Lee Mar 24 '17 at 4:15
1

My point is that it would limit it regardless. So what's the benefit? Is there a gain elsewhere, perhaps in the password cracking methodology?

Yes. While it's true that the rule limits overall entropy, I think the real question you should ask is how common passwords with three identical characters in a row really are.

Here's an experiment you could do: Get a list of common passwords (ten thousand most likely ones, for example). Count the number of passwords that contain three identical characters in a sequence.

Then calculate how often such a sequence should occur if it was distributed randomly. If there are more passwords with such a sequence than statistics suggest there should be, then people tend to prefer such passwords, which means that it makes sense to forbid such patterns, because password guessers would capitalize on this knowledge and try passwords with these repetitions first, which would greatly reduce the search space.

I haven't done the math, but I have a very strong gut feeling that the reduction in password entropy is the lesser problem IFF the identical-character-pattern is actually common in passwords.

If someone can calculate that for me and show me the steps, that would be greatly appreciated.

I'm too rusty to come up with a mathematically sound answer, but when I was still in school we calculated probabilities of drawing a number of black balls from a sack containing black and white balls, with putting the balls back. I think that would probably be the way to do the math correctly, and I think that since it's textbook probability, you might get lucky googling for this kind of problem.

For a quick feeling for the number of possibilities you'd remove with the not-three-identical-characters-in-a-row rule, think about what the chances would be to roll same number of eyes with a die three times in a row (the first one doesn't matter, but the following two throws each have a 1/6 chance, so 1/36). If you do the same with a password and assuming it's got 64 unique characters to choose from, you'd end up with a chance of 98.98% NOT to get an identical 3-character-sequence (1-(1/64)^2). However, this isn't correct yet because your password isn't just 3 characters long, it's 10 characters, so you'd have to take that into account. Possibly you have to multiply the chance to hit a three-duplicates-sequence (1/64 * 1/64) by 8 because there's 8 possible positions the sequence can be found in (which would still leave 99.8% of the original entropy)

Edit: Replaced math of questionable use with more sound math.

  • Lukas did do some research above. You make some good points. I actually thought this rule was 2 identical characters, not 3. Now I'm not as upset about it (we were going to use Auth0 and they follow OWASP rules by default). If it was 2, then that rules out so many words to the point of making dictionary attacks super easy. Should you limit password options at all? Does that really make it harder to crack passwords or easier? I think it's easier because generating the password list is fast compared to generating the hashes. – Geoff Lee Mar 24 '17 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.