Should or should not strong password contain user name

So the question is is good practice to have such rule to deny users to have UserName in Passwords?

For example if user type UserName User so he 开发者_如何学Gocan not have password which would contain User, or is it would be too hard to users?

May be better to just deny users to have UserName equal to Password but allow password to contain UserName?

What do you think?

According with that MS link http://windows.microsoft.com/en-AU/windows-vista/Tips-for-creating-a-strong-password strong passwords should not contain username.

May be better to just deny users to have UserName equal to Password but allow password to contain UserName?

Disallowing equality is a good thing.

Going further leads to the anti-solution (noted by glowcoder half an hour before I got here).

If the password is user-generated, then almost certainly yes if you are at all concerned about the security of the account. Given the choice, users are much more likely to choose their username as a password than a random password, and consequently, one of the first passwords an attacker is going to try. (The same goes for passwords like password 123456, abc123, and so on.)

This alludes to the concept of min-entropy. Essentially, if an attacker wants to guess a single password and doesn't care which password, the min-entropy is the expected number of attempts required. (This differs from slightly from standard password entropy, which is essentially: if an attacker wants to attack a specific credential, what is the expected number of attempts required?) If very simple passwords are allowed, the min-entropy value would be lower than it would be without complexity rules in place.

If the password is randomly generated, disallowing the username slightly decreases the entropy of the credential since it reduces the number of allowable password combinations. In practice, however, an attacker is likely to still try common passwords first, so detecting and restricting common passwords is probably good practice even so.