3

We have a discussion in our company about password security for our application.

Besides the fact, that we use 2 factor authentication (certificates+login/password), we currently enforce passwords with at least 12 characters of length.

Currently there is no enforcement of using non-alphanumeric characters. And from my perspective there is little to no gain in security, when the user is forced to mix (non)-alphanumeric characters.

From my understanding if you have the alphabet of possible characters, the entropy for 123456789012 and !"§$%&/()=!" should be the same and both passwords should have the "same degree" of security (the choices made from the alphabet differ, but the alphabet is the same).

The only difference would be the information to the attacker, that the first password uses only a subset of the alphabet, which would reduce the entropy.

On the other hand, what makes the first password "insecure" is the fact, that it is really predictable; chances are high for a fast match if a dictionary is used. Given slow hardware and a dictionary, it would really matter chosing one over the other.

But with todays power (GPU/Cloud) for bruteforcing the difference in security is from my point of view neglectable, so that it is valid to say: one is as secure as the other.

tl;dr

Is the difference in security between 123456789012 and !"§$%&/()=!" as passwords nowadays neglectable?

(strong hashing and using salts presumed).

Thomas Junk
  • 188
  • 7
  • 2
    If the users are a limited group of people in house (I get that impression, but might be wrong), I would recommend you to focus your energy on teaching people about password managers instead of making everybody add `1` to the end of their password. – Anders Dec 09 '16 at 13:56
  • Unfortunately, the application is customer facing with low it-knowledge. – Thomas Junk Dec 09 '16 at 14:02
  • 1
    Keep in mind that a sophisticated adversary who is specifically targeting and using brute-force methods (including dictionaries) will use every bit of information possible to limit their search space. So any password requirements are very helpful to them, such as knowing in advance that it must be a certain length, requiring special conditions (like must start with a digit or knowing that it must be a mix of upper and lower case, or requiring special characters) will backfire. The more information you provide to the attacker will only help them in their search. – SDsolar Dec 09 '16 at 15:39

1 Answers1

4

There are two factors here.

Firstly, you are correct, the entropy is the same. What is important is the address space not the utilisation of that space. So as long as users can use symbols etc, that's what's important in the first instance.

However, the second factor is guessability or breakability. Can a password be guessed using rainbow tables? Can a password be brute-forced (e.g. all characters the same). Your example of 123456789012 falls foul of this since it will certainly be in any decent rainbow table because it is simple and common.

So current best practice for passwords is that you allow extended characters but you don't enforce specific rules (which in any case reduce the address space). You encourage longer passcodes - "codes" note, removing the emphasis on "words" - good passcodes may be memorable but are not guessable. And finally, because you are encouraging complexity, you wouldn't be enforcing 30, 60 or even 90d passcode changes. At least for individual ID's, shared/admin ID's may be a little different.

My feeling is that this approach is a good balance of usability and enhanced security. But I think that you should ideally audit passcode databases periodically to hunt down weak passcodes.

Julian Knight
  • 7,102
  • 18
  • 23
  • Yes, I mentioned, that `123456789012` is easy "guessable", but does that matter when bruteforcing is cheap and easy? – Thomas Junk Dec 09 '16 at 14:05
  • Yes it does when using long passcodes. Since the number of possible codes increases by a multiple of your address space for each additional character in the code. – Julian Knight Dec 09 '16 at 14:07
  • Yes: I totally agree: When it comes to "long" passwords (=passphrases), predictability matters. This `topsecretpasswordijustmadeup!"§$%&/()=` is no longer a good password, when it is added to a dictionary, though it might have been one before. But only the fact, that it is now known makes it now a bad choice for the future? – Thomas Junk Dec 09 '16 at 14:14
  • 2
    You could argue that it is a collection of well-known patterns, that *might* be less secure - but I think we are getting a little esoteric here. One of the problems with passcodes is that of thinking you've created something unique which turns out to be really rather common. It would be interesting to look that phrase up in a good rainbow table :-) – Julian Knight Dec 09 '16 at 14:27
  • 1
    Long passwords are very helpful when facing an adversary who is using brute-force methods. But I wonder if it might actually lead to guessability because if the user must remember it, they might just use words that can be found in a dictionary, unless something like Lastpass is used which can generate random passwords. Fortunately, XKCD has answered this question: https://xkcd.com/936/ – SDsolar Dec 09 '16 at 15:34
  • All passwords suffer from guessability issues as indicated in my previous comment. However, in general terms, a longer phrase will be more secure for all practical intents. As always though, try to choose something not too obvious. – Julian Knight Dec 12 '16 at 09:21