[pdpi]

Considering how they deduct points for "bad practices", and how avoiding those "bad practices" actually makes for a smaller password space, I have half a mind to spend some time figuring out exactly how much smaller the password space is for a given length if you follow all of their advice.

[romaniv]

Any password rules decrease the overall possibility space. The point is that they try to move your password away from the high-probability areas of that space that hackers try first.

It's like kicking someone out of apartment. Yes, you know for sure they aren't anywhere in that apartment, but it still makes it harder to locate them in the city with high probability.

[Anderkent]

That's not quite right. Assuming you were picking passwords randomly discarding ones that have repeat letters etc makes for a smaller password space, certainly. However that's not how most passwords are generated, especially among the people that need this advice most. If your password generation algorithm is 'think out a random string' and produces 'aabbbbdccdc' then your password space is tiny.

Those practices are meant to address the most common 'patterns' in human-generated passwords, therefore effectively enlarging the password space (any cracker has to enumerate more complicated patterns or brute-force, rather than the simple pattern that our brains would generate by defualt)

[pdpi]

For each rule in isolation, that's true enough. But the point stands: once you add together all those good practices (repetitions, consecutive letters, multiple character sets), how much does that actually reduce the password space? I'm not saying that the space becomes tiny, I'm saying that it becomes smaller, and I'm not sure whether "smaller" is still acceptably large, and it's an assumption that's worth checking.

[KMag]

The cost in entropy for these restrictions isn't zero, but it's tiny and measurable.

As a conservative estimate, let's assume passwords are only chosen from a set of 84 printable ASCII characters and users never choose passwords longer than 10 characters. (If users are using characters outside this set or longer passwords, they'll have more choices than we're estimating.)

All combinations, including the null password yield 17700847248605297701 combinations, or 63.94 bits of entropy if a password is chosen truly randomly from this set.

Restrict them to passwords at least 7 characters long, and that drops to 17700846893074759680, about 1.9e-9 bits less, still above 63.94 bits.

Further add the restriction that no two adjacent characters are the same and that drops to 15894480881247564960, or 63.78 bits.

Further force the user to use one digit and that drops to 11477476711812418840, or 63.32 bits.

For the sake of my time, I'm going to get a bit sloppy and start over-estimating the cost of restrictions. Further force the user to have at least one upper-case and one lower-case letter and that drops to (more than) 10727550596265784840 passwords, or 63.22 bits.

So, all of these restrictions together cost less than 0.72 bits of entropy. That an easy price to pay for eliminating large classes of trivial passwords.

[pdpi]

Thanks for doing my "homework" for me :). Interesting, I seriously expected the repetition and adjacency restrictions to add up to a much bigger cost, to be honest.