Many registration forms prevent you from choosing a password that includes your username. Is it a reasonable restriction from security standpoint? I can see that if your username is "foobar" and password "foobar1" it's easy to guess, but shouldn't it be allowed if the password is otherwise strong enough?

Is n)_h322">L2=Q2*foobar really less secure than just n)_h322">L2=Q2*?


In a word, no. But that's not what usually happens.

Anything added to a password either makes it more secure, or no change at all. But since appending/prepending your username is so common, it tends to fall in the no change category in many use cases, which makes password strength verification very difficult.

For example:
Username: JonathanParr27
Password: JonathanParr27!

Here, the password is simply the username with a ! appended. The password does contain a capital, lowercase, digit, and punctuation, plus it's 15 characters long. By typical metrics, it should be a good password. But an attacker will try appending numerals or punctuation to the username on brute-force attempts, so now this long, complex password can really just be reduced to username + !, which is quick and easy to guess.

As such, most places with secure password requirements will simply say, nope, if you use your name in your password, it's no good. This both simplifies password strength verification and also puts an end to the silly practice of using your username as the basis for your password.

| improve this answer | |
  • "Anything added to a password either makes it more secure, or no change at all.". I have some doubt about that. I mean, concatenating 2 strings could result in a common word, or something easier to guess. An example would be please hold we are locating the nextel + suscriber you are train to search; while the 2 parts can be considered quite strong, the concatenation can be found in the rockyou.txt dictionnary. – Yuriko May 30 '16 at 6:43
  • @Yuriko OK, in the extraordinarily narrow case where string X isn't in any cracking dictionary but sting X+Y is, then yes. But I think we can all agree that the real-world likelihood of this is either zero or close enough to zero to ignore it in any risk calculations. – tylerl May 31 '16 at 4:53

TL;DR Password policies aren't really made for people who user random generators to generate passwords with 96 bits of entropy. They're made for the vast majority of people, aka lolcat viewers.

The entropy of a password comes from how the password was generated rather than the characters it does or doesn't contain. For example, the randomly generated password kztc0!#F2mZq has 79 bits of entropy. If an attacker knows that you like to add your user to the end of your passwords, then kztc0!#F2mZqfoobar has exactly the same entropy as kztc0!#F2mZq, i.e. the latter is as secure as the former.

Now, here's the interesting part. If the attacker suspects that you add your username to the end of your password, then kztc0!#F2mZqfoobar has, unintuitively, only one more bit of entropy than kztc0!#F2mZq. If the attacker knows that you have your username in your password but doesn't know the exact location, then kztc0!#F2mZqfoobar has 3 more bits of entropy.

Now, back to reality. In practice, most users don't generate random passwords and prefer using passwords like mylovelyann1982 or lolpassword999. They usually choose passwords between 6-10 characters. So if 4-5 of those characters in the originally-low-entropy password are the username, that would make the password even weaker. Those passwords are targeted by such password policies.

| improve this answer | |
  • To be precise, if you have a 12-character password into which you insert the user name at some randomly chosen place (that is, the attacker has no clue whatsoever as to what place you inserted the user name), then, since there are 13 possible insertion points in a 12-character password, the additional entropy is log 13 (base-2 log), i.e. about 3.7 extra bits of entropy. – Tom Leek Nov 3 '13 at 14:30
  • However, users who insert the user name in the password generally won't insert it at a really random place, if only because that's one more parameter to remember. Most will add it at the end or at the beginning, and the attacker can know that, too, so the extra entropy will be less than 3.7 bits in practice. – Tom Leek Nov 3 '13 at 14:31

It may make sense to count the number of characters in the password which do not appear to be recognizable parts of the user's profile. For user "gere", there shouldn't be a problem with password "cabinet triggered frederickson", even though it contains "gere", since it also contains "cabinet trig" and "d frederickson". For user "freddy932", however, a password "freddy!" contain anything of significance other than an exclamation mark.

| improve this answer | |

On including username in the password you are making the brute-force attack easier, as attacker knows some characters already about the password. It significantly reduces the guessing time. In case of "foobar1" as you said, it certainly becomes easy for the attacker to guess.

In case of n)_h322">L2=Q2*foobar, the strength of the password is surely less than that of password having same number of characters but not containing the username.

But that is all part of theory, in practice users don't keep passwords which are hard to guess or they keep passwords that are easy to remember. Due to already lack of enough randomness to make guessing difficult, websites advice to not include usernames in the passwords.

Is n)_h322">L2=Q2*foobar really less secure than just n)_h322">L2=Q2*?

Assuming the attacker knows that user is using username in the password, then for each password guess attacker needs to try it out with combination of username. For eg, attacker needs to try out foobarn)_h322">L2=Q2*, n)_h322"foobar>L2=Q2* etc. So n)_h322">L2=Q2*foobar should be a bit more secure than just n)_h322">L2=Q2*

| improve this answer | |

As was pointed out by others, adding extra "known" characters does not make the password less secure, since entropy is a measure of how many other values the password could have assumed -- and a systematic deterministic appending of characters does not change that number.

However, there is a feedback. The password is chosen by a human and will be typed by a human, and is constrained by three kinds of rules:

  • The user will have to remember the password.
  • The user will have to type the password (often).
  • The password policy will usually enforce a minimal size.

The "minimal size" policy is a way to prevent users from using 3-letter passwords or so. Indeed, users tend to maximize their utility function (as economists say), i.e. they will use passwords which make their life easier. A very short password is easy to type and easy to remember. But this often leads to passwords which are way to easy to crack, hence a policy of having a minimal size (often 8 characters). In that context, appending the user name has two evil effects:

  • Since the user prefers short passwords when he has to type them, this will incite the user to reduce the amount of "random characters" in his password.
  • The "minimal size" policy is bypassed.

Indeed, if the user has name "foobar" and needs to comply with a policy of "at least 8 characters" then he will try for use a password like "foobar42", which is not safe at all... since its effective length is then 2 characters, not 8.

The bottom-line is that while inserting or appending the user name in the password does not reduce security when all other things remain the same, the other things tend to be altered at the same time. In particular, a "minimal size" policy should be altered into: "at least n characters excluding a copy of the user name, if applicable". You want "foobar42" to be measured, for this policy, as a password of length 2, not 8.

This also illustrates the creativeness of human users. They will try hard to work around your policies if these policies make their life harder. To achieve better security, you really need to obtain the user's cooperation, which implies a lot of pedagogy, and helper tools (in particular, you should provide a non-mandatory password generator, for users who want to generate a good password -- some will use it).

| improve this answer | |

If it is not usefull, don't do it!! As it could become harmfull.

Ok, adding your username to already decided strong password seem to be innocent. But:

  • If someone are looking for your finger move, the more keys you hit, the more are chances to rightly interpret by sound, movement and time between hits.

  • Adding useless** characters will improve the possibility you hit a wrong key, forcing you to re-type the entire password. Giving another chance for better movement recognition.

** I said useless because adding your username add at best 1 bit of entropy.

| improve this answer | |
  • One bit of entropy still doubles the number of possibilities. Upon a database hack, it will take (on average and all else equal) 1.5 times longer to crack your password than it would without appending/prepending your username. It also works as a sort of salt, which would have been useful in Adobe's recent case (encrypted password database hack). But I don't downvote because in principle you're right: it's not that useful, and not everyone would know if there is some sort of vulnerability in it (not everyone knows how hashing works), so better don't do it if you don't know the result. – Luc Feb 3 '14 at 0:06
  • Brute force and password db are not the only way used by attackers! Adding 1 bit of entropy by adding many keys to hit improve the chance you mis and re-type, this improve the chance an attacker watching your move understant thems. – F. Hauri Feb 3 '14 at 6:39

Many registration forms prevent you from choosing a password ...

Unfortunately, many registration forms have no idea how to tell good from bad passwords, and create almost arbitrary restrictions, including the truly ridiculous, such as a maximum password length, not being allowed to use special characters, etc.

Passwords work in terms of entropy, where the true entropy can only be observed by knowing what the thought process was while generating it (that's why the forms cannot simply measure entropy and tell the user to get higher entropy). Essentially, if an attacker knows the thought process and tests random passwords that use the same process, entropy tells us how long it takes until the attacker tries the matching password.

For example, if I have a given password and decide to add a number, this adds a single character and multiplies the password space by 10 ('pwd' becomes either pwd0, pwd1, pwd2, ...). On the Other hand, if I have a given password and decide to either append my username or not add it, this adds several characters and only multiplies the password space by 2, if the username is known to the attacker. If I either use the username as a prefix, as a postfix, or not at all, this multiplies the password space by 3, which is still much less than adding a single random digit.

So making your username part of the password makes a stronger password than not doing so, but a (much) weaker password than adding pretty much anything other than your username instead.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.