1

In the early days we happily saved whatever password a person wanted to the database.

Later we decided that passwords must include certain characteristics like numbers, upper and lower case and defined lengths (sometimes a max of 8; yikes!).

Not too long after that some of us decided that certain characters like ; and ' (gotta love people fixing sql injection the wrong way) and even repeating sequences like aaa were no longer allowed.

At some point we finally hashed them and shortly thereafter added a bit of salt.

Now, I'm wondering, do any of the requirements around password "strength" really matter? In other words, if we stripped away all of the characteristics EXCEPT for a minimum length is it just as good?

If my app says, the minimum password length is 12 characters and up to 200 characters - essentially a pass phrase and I allow them to use any character they can type on a keyboard, then is it just as hard to break through the front door? Presuming that I am still hashing with a salt when it's stored in the DB?

-- note: I'm not looking for opinions. I'm looking to see if anyone can provide a "proof" that a 12 character pass phrase is less secure than one which has common limitations identified above.

NotMe
  • 696
  • 3
  • 11
  • @TerryChia: Not exactly and your answer on that one failed to actually answer the question anyway. – NotMe Feb 06 '14 at 15:54

1 Answers1

6

Ok, let's get things in the right order.

First, you may doing it wrong. This is about what you say about "a bit of a salt". You don't say if you use "we" as meaning "me at my job" or just "we" as in "we Information Security professionals, generally". If it is the former, then it seems that you are using a homemade hashing construction, probably one or two hash function invocations of a hash function with the salt value appended haphazardly somewhere in the mix. This does not bode well. Password hashing is a complex matter, with theory and existing active research and well-vetted candidates. Read this answer.

That being said, let's see your actual question, i.e. are "password strength rules" useful ? To this I must answer: in practice, no. See this previous question. Any constraint is likely to turn the user into an uncooperative user, who will employ defensive mechanisms in order to ease his own life, such as writing down passwords or generating passwords "with a hidden meaning". That's counterproductive: these user behaviours are triggered by the strict password rules and their overall effect is that security is lowered, not increased.

A minimum length can be enforced because a too-short password is unambiguously weak and users understand that. So you do not alienate your own users by enforcing a minimum password length. However, any other rule tends to backfire.

What makes a good password is randomness. Password rules are just ways to push users out of their comfort zone, on the hope that once they are required to put punctuation symbols and letters and digits, then they will, in some unspecified way, begin to "act randomly". This does not go that way in practice. Uncomfortable users are angrier, but not more random.

What can help is to give to the user a non-mandatory password generator which uses randomness. Computers are better at randomness than humans.

(See also this previous question; its answers may illustrate the relationships between randomness, security and usability.)

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Although a decent answer, perhaps a different phrasing of the question will help. I'm talking about brute force attacks through a standard web login screen using a min 12 character length alone. Would it be better to simply have an attempts counter that stops them at say 50 attempts than to force users to use punctuation, numbers and what have you? In other words, you claim randomness is important. Looking over some of the password lists that have been released the common ones are almost always 8 characters. By requiring 4 more then we are naturally introducing randomness. – NotMe Feb 06 '14 at 16:43
  • @NotMe Yes, your UI should stop after some number of failed attempts, but you need more than that since the attacker won't always go through your UI. For instance, the whole idea of storing a password hash instead of the actual password is to defend against various situations where an attacker can gain temporary read-only access to your database. – Ixrec Aug 19 '15 at 21:13