Should I really have password requirements on my website?

Question

Say a user signs up for my website. Wouldn't requiring certain password criteria be a "bad" thing, since it could give a potential hacker a starting base on how to guess the password?

For instance, if I say the password has to be at least eight characters, have one capital and two numbers, doesn't that give the hacker too much information on all of my user's passwords?

Ultimately, my question is would it be a good idea to implement an application which could provide random password criteria rules so there is no "global" criteria?

Logical function:

critera = {
    random_1: <password must be more than five characters and have two numbers>
    random_2: <password must be more than six characters, cannot use numbers>
    random_3: <password must be less than eleven characters and start with a captial>
}

<random loop for sending criteria.random_x to any random user signing up for an account>

I program my websites in Python, so if I were to do this, would there be any security risks to doing it this way? Or, is this way just in general a bad idea? If so, why?

Answer 1

This is probably going to get downvoted because it is opinion-based, but It's a good question so I'll attempt to answer it anyway.

"doesn't that give the hacker too much information on all of my user's passwords?"

This is true, it does give a hacker some grounds to start with when applying a dictionary attack or another means of cracking. However I do believe there should be some grounds for password requirements.

For example,

Password must be at least 6 characters, one capital letter, one number, and at least one special character.

I've actually seen this before, and it's complete overkill. But, without any requirements, users are prone to setting their password as something extremely simple. Without requirements, the security risks are actually greater than if there are some requirements involved.

A better example:

Password must have at least one capital letter and one number

A good idea would be either your random requirements suggestion, or simply require a number and maybe a capital letter. At least in this case, there is much more security than someone using their password as 'abc123'

Another thing to note is that the more requirements you have, the more the attacker knows about the password, but the harder and longer it would take to crack the password. It already takes a fairly long time to perform a dictionary attack without any capital letters or numbers. With numbers, capitals, and special characters, which could be located anywhere in the password, is much harder to crack, even if you do know what it requires.

Answer 2

Good question, but requiring special characters would definitely require a hacker to try many more combinations outside the standard dictionary if using brute force to crack a password which is not an effective cracking method anyway. Also, as an additional security measure, you can "lock" the account after a given number (usually 3) of attempts...

Answer 3

the password has to be at least eight characters, have one capital and two numbers, doesn't that give the hacker too much information on all of my user's passwords?

Let's see. Ignoring punctuation (since not many people bother to put any in their passwords unless forced to), there are 62 characters that commonly appear in passwords. Some more commonly than others, of course, since most passwords aren't randomly generated.

Let's compare what happens if we just say "minimum 8 characters" compared with what happens if we make the additional restriction. Let's also assume the worst case password, that's only as long as the minimum.

The number of possible passwords if any combination of characters is allowed, is 62**8, which is 2.2 * 10**14

The number of possible passwords with the restriction of one capital and two digits is (um, I'm not great at combinatorics) more than 62**5 * 26 * 100, which is 2.4 * 10**12.

So the attacker certainly has more information: the total space of passwords is 99% smaller. But is it too small? Is it likely that this difference in size, 2.4 trillion vs 220 trillion, will make the difference between an attacker brute-forcing the password and not doing so?

Probably not. And even if it is the difference, you can get most of the space back just by requiring 9 characters instead of 8. So you are not increasing the risk for users who understand what they are doing and choose strong passwords.

I'm not entirely convinced myself that requiring capitals and digits in passwords is the best way to strengthen them, but if it prevents users from using a dictionary word, you've put some kind of hurdle in the way of attackers. You've eliminated the worst passwords from that space, which means you have (hopefully) made "the easiest password to guess" on your site at least somewhat harder to crack. And that's about all you can hope to do with these simple restrictions on passwords.

You do have to think a bit about your threat model. For example, there is a period of time, and I don't know for sure whether that period is past/present/future, during which a 2 trillion entry rainbow table is computationally feasible but a 200 trillion rainbow table is infeasible. I suspect that period lies in the past for the most able attackers on the planet, and in the future for the average cracker, but that whenever it occurs this era of history is a short one and therefore you don't want to base your website's security on the assumption that it is in the present for your actual attackers.

Now, would applying different password criteria to different users be better? It would, if an attacker is applying an attack that benefits from the smaller password space. But if any of the restrictions is weak ("more than five characters and have two numbers" being the weakest in your list of examples), then that will still allow some users with weaker passwords than if you just used the strongest restriction for everyone.

So basically no, I don't think applying at random one of several criteria of equal worth won't do any significant good. The very best it could possibly do is multiply the size of attack needed, by the number of different criteria you choose from. That's if the different rules produce completely non-intersecting spaces of passwords, so actually it won't be that good.

Requiring a capital letter or a digit is pretty much a psychological trick to encourage your users to choose non-dictionary passwords, and maybe to make the user think a bit about what they're doing. If it works, that's great, and it will work whether you apply the same rule to everyone or not. The space of permitted passwords is pretty much irrelevant compared with the space of passwords that your users actually think of and use.

If you want to stop your users choosing weak passwords, be sure that your restrictions, however they're applied, block the most commonly-chosen passwords (http://gizmodo.com/5954372/the-25-most-popular-passwords-of-2012, https://xato.net/passwords/more-top-worst-passwords/). Those are certainly among the first that any brute-force attacker will try. Many of those contain digits. It's not possible to tell whether they contained capital letters because the researcher has lowercased everything.

It's fairly important to note that according to the researcher 91% of exposed passwords fell into the top 10k (case-insensitive). So even allowing for one capital letter in each password, and an average length of 6.3 characters, an attacker can brute-force 91% of accounts in 63k guesses. If you allow users those passwords, it would take something of the order of a day to find it in an online attack from a modest botnet if you're lucky. A few seconds in an offline attack against a list of securely hashed and salted passwords.

Getting rid of those most-common passwords is absolutely necessary to make it hard for attackers to brute force. The exact size of the password space is far less important.

Answer 4

When you require a capital letter and a number (and at least 8 characters), you're really saying, "at least 8 characters, but not a dictionary word", without having to actually check their password against a dictionary list.

Here's what you end up with as passwords though--you get the most common passwords, with capitals and numbers mixed in:

• Password01
• L3tM3In!
• Jennifer01

You're basically asking people to add their own additional random salt, but it's not really random.

You also end up with passwords that people can't remember or they use the same password everywhere.

Password policies are fine. It's unfortunate that you have to try to protect people from themselves. Just make sure you provide a secure way for people to reset their forgotten passwords and have code in place that detects and prevents brute force attacks.

Answer 5

The core of the question, as clarified in a comment, is: Is using a randomly-chosen set of password restrictions better than one universally global restriction?

Technically, yes, it is better, simply because you're imposing a bit of unknown information on the password.

But it isn't very advantageous. If you have n sets, then at most you've increased the attacker's work by a factor of n, because the worst-case scenario for the attacker (best-case for the developer) is that they have to perform the work independently for each of the n restrictions.

For the case n=3, this isn't much of an improvement. Multiplying the necessary work by 3 is the equivalent of adding about 1.6 bits of work. In the big picture, that's insignificant. An attacker who could attack with the case n=1 can still attack with n=3, or even n=10, they just have to be a bit more patient. For real security, you want to use schemes that increase the work factor by at least 10 bits (or, n >= 1024).

To be effective, the password restrictions should impose conditions that are:

• mutually exclusive to each other
• force conforming passwords to not resemble a standard set

The provided example password restrictions have overlap and don't impose any useful conditions. Half of both random_1 and random_2 will be subsets of random_3. random_1 and random_2 are indeed disjoint themselves (due to the numeric restrictions) which is good. But the key problem is that random_3 doesn't deviate from the standard "anything is allowed" key space by much, and the others deviate only by a little. The attacker won't do 3 different attacks, they would just launch a standard attack as if they knew nothing about the restrictions and they'd incidentally attack everything allowed by these examples. These specific examples actually add very little. Dictionaries based on simple lowercase+uppercase, lower-case+numbers, etc, combinations are widely-used.

All that said, adding overhead to the attacker's work is a really good idea. In fact, it's a problem we've already solved: Use a password hash function that takes a "work" parameter. Such a hash allows the developer to specify how much internal work must be done in order to compute the password hash, thus allowing the developer to choose how much work the attacker has to scale by. This is a more formalized and practical version of what you propose, but it's more scalable, widely supported, and simpler. Two popular such hashes I would recommend would be bcrypt (python example) and scrypt.