21

Does the act of requiring certain criteria for passwords make them easier to brute-force?

It's always seemed to me that when websites limit the use of "insecure" passwords, it might make it easier for the passwords to be brute-forced because it removes the need for attackers to check any of those passwords. The most basic of these requirements (and probably the most common) would be the need for a password to be 8 characters or longer. It has been discussed in a few other topics:

The general consensus on this is that requiring longer/harder passwords doesn't necessarily make them easier to crack because most of the passwords it is not allowing aren't probable passwords anyway (because the great majority of people wouldn't use a random string of characters).

I still feel like most people are probably using a password that is the required length or only 1 or 2 characters over the limit. Assuming the use of only alphanumeric characters, requiring 8+ characters removes about 3.5 trillion password possibilities (most of them would just be random gibberish). This leaves ~13 quadrillion passwords that are 8-9 characters. My main question is: Would it make more than a negligible difference in security for websites to only have password requirements sometimes?

Example: Maybe 1/100 attempts to create a password would not need to meet a certain criteria, which would require attackers to test all passwords because of the possibility that the password is less than 8 characters

Community
  • 1
MisterEman22
  • 313
  • 2
  • 6
  • 1
    possible duplicate of [What technical reasons are there to have low maximum password lengths?](http://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password-lengths) –  Aug 20 '15 at 04:01
  • 2
    @begueradj My question is nothing like that... did you even read my question? – MisterEman22 Aug 20 '15 at 04:41
  • 2
    Just about your example: If you were to allow 1 in 100 passwords to have different criteria, this does NOT mean that the cracker needs to take that criterium in account. In the best case it will probably result in him cracking 'just' 99% of the passwords. – Dennis Jaheruddin Aug 20 '15 at 09:44
  • @DennisJaheruddin I didnt put much thought into the exact numbers there, just an arbitrary value to convey the concept. I figured if anything like that was used, more thought would be put into the actual numbers – MisterEman22 Aug 20 '15 at 12:11
  • 1
    @MisterEman22 I always says being too restrictive with passwords is the best to found a post it in the first drawer of peoples’s desk. – user2284570 Aug 20 '15 at 18:03

5 Answers5

58

One related question that you missed in your list is this one:

How critical is it to keep your password length secret?

The accepted answer there (disclaimer: mine) shows that if you have a password scheme which allows all 95 printable ascii characters, then the key space ramps insanely quickly every time you increase the length of the password by 1. You can check all the passwords up to length N in about 1% of the time that it'll take you to check only passwords of length N+1. By rejecting any password shorter than some cutoff length, you give up far less than 1% of your key space.

So, I strongly second @Iszi in saying

The benefit gained by forcing increased length far outweighs the number of possible passwords lost.

Next point: let's get out of the idea that 8-characters is long for a password. It is not. You say "~13 quadrillion passwords" as if that's a big number. It is not. According to this article (which is a great read btw) his password cracking rig could make 350 billion guesses per second, so every single one of your ~13 quadrillion passwords can cracked one-by-one in ~10 hours. And that's on 2013 hardware, GPUs have come up a lot in power since then.

My opinion is that websites can squabble about who has the better password requirements, but they are all far too weak. Our ability to crack passwords is growing WAY faster than our ability to remember longer ones. This is because security is clashing with usability. Try telling anybody who's not a tech nerd that they need to memorize a 32-character password that doesn't contain any English words, and a different one for each account they have! You'll be laughed at and then ignored. Websites that try to enforce anything better than pathetic password policies have to deal with mountains of angry customers.

The solution is to do away with passwords all together and move towards strong 2-Factor type authentication, where offline cracking isn't feasible. Unfortunately companies have only been seriously thinking about alternatives to passwords for less than a decade and the offerings are far from polished (they are plagued with convenience and usability problems which are preventing mass adoption), so in the meantime we get to continue having these useless debates comparing one mostly useless password scheme against another. End opinion.

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • 1
    Regarding your opinion section, do you believe technologies like bcrypt will eventually succumb to growth in computing power? – David Zech Aug 19 '15 at 22:05
  • 2
    Password hashing functions like bcrypt help because we can keep cranking up the number of iterations as CPUs get faster, but they still rely on a user typing the same password into the box every time, so it just moves where the weak link is. – Mike Ounsworth Aug 19 '15 at 22:10
  • 1
    Accepted because you answered the main question i had which was whether the attacker needing to check the first 3.5 trillion would have a negligible effect on efficiency of cracking – MisterEman22 Aug 19 '15 at 23:06
  • *You can check all the passwords up to length N in about 1% of the time that it'll take you to check only passwords of length N+1.* Sick fact. Is this backed up or just an estimated suggestion? – Mike Aug 19 '15 at 23:45
  • 1
    @Mike A bit of both. Check [the linked question](http://security.stackexchange.com/a/92238/61443) for the math on how I came up with that number, post a comment there if you want more info. – Mike Ounsworth Aug 19 '15 at 23:48
  • 15
    @Mike There are 95^N passwords of length N. So for any length N, there are 95 times more passwords of that length than for length N-1. 1/95 ~= 1%; QED. – l0b0 Aug 20 '15 at 07:08
  • 1
    Microsoft is trying to step forward with the idea of a password-less future with [FIDO](https://fidoalliance.org/microsoft-announces-fido-authentication-support-planned-for-windows-10/). This introduces the possibility of biometrics (face/voice/fingerprint recognition). Of course, we have to make sure *this* is secure, otherwise someone can just snap a 50 megapixel shot of your fingerprints... – phyrfox Aug 20 '15 at 17:16
  • I largely agree, but I'm curious how you feel about [passphrases](https://xkcd.com/936/) as a stop-gap (particularly used in conjunction with password managers like LastPass and 1Password). – Kevin Aug 20 '15 at 20:45
  • 1
    @Kevin You make two points: 1) whether you call them _passwords_ or _passphrases_, I'm ok with them as long as they're over 30 characters. 2) Password managers like LastPass and 1Password are awesome, but they're not ready for prime-time (aka they're not grandmother-proof); the hassle you have to go through if you forget your master password, or break your device, is more than the average user is willing to put up for a bit of extra security. (remember that if you force passwords longer that 12 chars, the majority of users will Post-it it to their monitor.) – Mike Ounsworth Aug 20 '15 at 20:58
  • @Kevin If you're using a password manager, presumably it's because you've lost the ability to memorize some or all of your passwords. At that point, you may as well just switch to fully non-memorable and random-generated passwords for best security. – Iszi Aug 21 '15 at 14:15
  • @Iszi: At least some of the managers on the market today actively encourage doing just that. LastPass, at least, provides a random password generator which is integrated into the manager. – Kevin Aug 21 '15 at 14:16
  • 1
    @Kevin KeePass has that covered as well. – Iszi Aug 21 '15 at 14:18
  • @Kevin - though one must be careful with integrated password generators. I ended up having mine set to a stupidly-long password and kept running into sites with MAXIMUM password lengths (one of which didn't manifest until AFTER I had the password set). – Michael Kohne Aug 21 '15 at 20:29
11

The answer is in your question.

Assuming the use of only alphanumeric characters, requiring 8+ characters removes about 3.5 trillion password possibilities (most of them would just be random gibberish). This leaves ~13 quadrillion passwords that are 8-9 characters.

Establishing a minimum length, or even an exact length, for passwords forces the user to choose a password that's in a search space several orders of magnitude larger than the number of weaker passwords that such requirements invalidate.

To better illustrate this, let's simplify and actually write out whole numbers here. Assuming all-lowercase alphabetical-only passwords, there's:

8031810176 possible passwords of length 7 or less.
200795254400 possible passwords with length of exactly 8.

Increase the number of possible characters, and the number of passwords lost becomes even more insignificant in comparison to the complexity that's enforced.

The benefit gained by forcing increased length far outweighs the number of possible passwords lost. And the passwords that are eliminated pose far too high a risk to be allowed when such a simple and effective countermeasure is available.

Iszi
  • 27,027
  • 18
  • 99
  • 163
3

Not uniformly applying a password policy introduces unnecessary security risks and definitely does not improve security.

Allowing weak passwords to exist just improves the likelihood that the attacker will crack a hash using a list of common passwords. This problem is made worse as the number of users increases. If 1/100 accounts have a password that doesn't conform to the password policy and 100,000 accounts exists, 1000 accounts are going to have weak passwords.

Also, It's actually more work to only selectively enforce a policy for only a subset of users than it would be to enforce the policy for all users because the application would need specific logic to not enforce the policy under certain circumstances. It's easier to require a strong password policy and uniformly apply it to all accounts.

Justin Moore
  • 769
  • 4
  • 9
3

This is not a good idea.

I would also like to quote the question:

I still feel like most people are probably using a password that is the required length or only 1 or 2 characters over the limit.

Agree! Well, I don't actually assume people to create passwords of one or two characters if you set the minimum length to 0, but most of your unrestricted users will not create long passwords. So an attacker now just needs to try the short passwords, the most common one (the likes of 'qwerty' and 'dragon') first, to exploit these people and be more successful than if you had enforced the restriction completely, since as you said there are orders of magnitudes less passwords under 8 characters than above.

Alternatively one can continue attacking the portion of users that you still imposed the minimum length restriction on and run away with - in your example - 99% of the "loot" (see @Dennis Jaheruddin 's comment). In password security it's all about orders of magnitude, so that doesn't really help much - it's offset by an 1.01% (1/99) increase of cracking speed. (Fun fact: Moore says that's done with in 8 days.)

Leif Willerts
  • 155
  • 3
  • I like the "fun fact" at the end... while improvements are quantized and not continuous, it's still worth contemplating that on average, according to Moore's Law "computers get 1% faster per week". – Floris Aug 20 '15 at 13:22
0

Sometimes password protection coded bad - as in NT LAN Manager (NTLM) realization for example. If dictionary words or predictable ordered sequence used in password - 7 symbols is better then 8 or 9 10 or 11 or 12 or 13, because password is splitted into 7-characters parts before hashing and encryption/

Look for details here: https://security.stackexchange.com/a/21267

Community
  • 1
Roscha Hacker
  • 1