More on password security / Follow-Up: My recent problems with Unitymedia

An expansion on the password security issues briefly mentioned in my previous post.

Returning to and setting the hotspot password, I was faced with the following rules (paraphrased into English):

1. At least 8 characters, at most 64.

   A lower limit of 8 characters is very weak in today’s world, and negates much of what is attempted to be gained by the other rules.

   (Any upper limit is sub-optimal, but it is hard to avoid having a limit somewhere, 64 should be enough for these purposes, and compared to some idiots who actually put upper limits of e.g. 16 characters, it is quite good. Some banks go to extreme lengths to increase security with various TAN-mechanisms, yet leave the online-banking password/PIN at exactly 5 characters…)

2. At least one upper-case letter.

   This is obviously geared at nitwit users who chose too easy passwords, up to and including “password”. However, it also reduces the search space, making life easier for crackers of random passwords—and it poses a problem during password generation: Especially with shorter* passwords (say 12 characters) and in combination with the following two items, there is a non-trivial risk that a randomly** generated password will not be conformant. To boot, such restrictions only look at one aspect of a password and a password of 11 characters made solely from lower-case letters will be more secure than 8 characters mixing upper/lower case and digits.***

   *And note the below item where a longer password will be more likely to be non-conformant: Unitymedia has us coming and going.

   **A randomly generated password is almost always the best choice from a security point of view. A randomly generated “ertya123456dmqpdfe” will be more secure than a manually chosen “consTituti0nal_amendMent”, despite the conspicuous digit sequence and other violations of these rules, and despite being shorter. To boot: If everyone used random passwords, these rules would be entirely redundant and dictionary attacks (cf. below) pointless.

   ***Assuming 26 letters, the former has 26^11 combinations, while the latter has (2 * 26 + 10)^8 combinations. The former wins by a factor of roughly 17…

3. At least one lower-case letter.

   As above.

4. At least one digit (literally, “number”/“zahl”).

   As above.

5. Special characters are allowed (e.g. !@#+-=).

   Good: They should be.

   However, it is extremely unlikely that Unitymedia is set up to handle all variations (cf. the next item) and a complete listing should be given. Also, someone who does use special characters increases the risk of violating one of the preceding rules with an automatically generated password.

6. No spaces.

   An arbitrary restriction that should not be needed with correct password handling by Unitymedia, and which reduces the search space. This might be an attempt to protect users against confusion arising from (accidental) leading or trailing spaces, but, if so, the rule should not apply within the password. More likely, there is some deficiency in Unitymedia’s systems that falls on its face when spaces are used.

7. No consecutive letters or digits [literally, “numbers”/“Zahlen”] (e.g. 123, abc).

   Firstly, this is a very unclear rule, making it hard to determine what the actual restrictions are. What is almost certainly meant, based on knowledge of common password errors and the examples, is that there must be no string of one letter (or digit) followed by another which is “one higher”. That is not what is said, however: The most reasonable literal interpretation would exclude e.g. “145” and “azt”, because we have digits or letters following each other in the string. Other potential interpretations are possible, however. The examples used make it unclear if e.g. “12” would be OK.

   Secondly, this rule is highly problematic for those using password generators: With a long password, the chances that a perfectly random password does contain one or several such combinations is fairly high, even assuming a minimum of three characters. Assuming just two characters, automatic generation will fail very often.

   Thirdly, without additional protection against e.g. “321” or “135”, this rule is toothless.

   Fourthly, even non-random passwords are weakened, because the search space can be reduced.

8. Must be different from the customer-area password.

   Strictly speaking, it is a good thing to use different passwords for different objectives. However, without also banning trivial variations (e.g. just adding a “1” at the end), the benefit of this is small. It it also well-known that the more passwords users have, the more likely they are to write them down or cheat* in other ways, thereby turning the security advantage into a disadvantage. This risk is particularly large with unsavvy users, which is exactly the group these rules are so obviously targeted at. Of course, a much worse error would be to use the same password for two entirely separate services, e.g. Unitymedia and Hotmail; however, here there is no restriction**.

   *E.g. through using trivial variations, foregoing random passwords in favour of “dictionary” passwords, resorting to personal facts, …

   **For practical reasons, such a restriction would likely have to be limited to an admonition. This admonition, however, could well bring more benefit than the Unitymedia-internal technical restriction…

   (It also very, very slightly reduces the space of available passwords/the randomness of possible passwords. In this case, it is highly unlikely to have any practical effect, but similar rules would be detrimental in a cryptographic context.)

Two additional weaknesses are:

Firstly, no mention is made of what happens with letters not normally present in German, e.g. “å”, or Unicode variations of letters that happen to look the same but are considered different. This is not only a major source of insecurity for the foreign user (for instance, a Chinese user might prefer to have an all-Chinese password), but also makes it very hard to judge search spaces. For simplicity, I go with the English alphabet and 26 letters above.

Secondly, the single greatest danger is the use of passwords vulnerable to a dictionary attack, e.g. “consTituti0nal_amendMent”. These, however, are not banned. A dictionary of, say, 100,000 words is almost certain to contain “constitutional amendment”. It has 24 letters (including the space). Allow a geometric average of three* variations per letter. We could now take 3^24 * 10^5 as an estimate of the randomness of this password. This is a smaller number than 26^12, corresponding to a perfectly random string of 12 lower case letters. It is actually almost as weak as a mere 8 random characters from a 100 character space, as could be approximately achieved by mixing upper/lower case, digits, and special characters from a regular German keyboard.

*Most will only have two, the upper and lower case, for such naive transformations. Some will have three, e.g. “o”, “O”, “0”. Some could have more, e.g. the space being replaceable by any special character. Also note that the above randomness estimate is likely on the generous side, because most other words in the dictionary will be considerably shorter. (The above, however, is only intended to give a rough ballpark figure—not as a stringent mathematical analysis.)

As an aside, what weaknesses are the more severe can depend on the type of attack attempted and the surrounding circumstances. Is the attacker looking to crack one specific account or any account? Does he have access to e.g. a set of hashed passwords that he can attack off-line or does he need to attack through the log-in masks? Etc. Notably, if a non-random password is used and a specific account is attacked, then “social engineering” is likely to work better than a dictionary attack.

Advertisement