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).

Improve this question
3
  • 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 9, 2016 at 13:56
  • Unfortunately, the application is customer facing with low it-knowledge.
    – Thomas Junk
    Dec 9, 2016 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 9, 2016 at 15:39

1 Answer 1

Reset to default
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.

Improve this answer
6
  • Yes, I mentioned, that 123456789012 is easy "guessable", but does that matter when bruteforcing is cheap and easy?
    – Thomas Junk
    Dec 9, 2016 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 9, 2016 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 9, 2016 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 9, 2016 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: xkcd.com/936
    – SDsolar
    Dec 9, 2016 at 15:34

Not the answer you're looking for? Browse other questions tagged .