Talk:Password length & complexity
The overall content is correct, but I have the following remarks :
1. I corrected some syntactical errors in the text. For example, "is" was missing in the sentence "it is the most common form", in the introduction.
2. The introduction could insist on the idea that passwords are basically a means of authenticating users of a Web application, among other means, and that the choice of passwords or a stronger means like two-factors authentication really depends on the security needs of an application, based on risk evaluation and security specifications in the conception phase.
3. In the introduction about the "Pros" and "Cons" of passwords, I would add in the "Cons" that we all suffer from having to manage and remember too many passwords. For a new Web application, one should consider the possibility of relying on a more global identity management system (such as some sort of "single sign on" or "reduced sign on" set for all or at least many applications in the corporation), instead of trying to generate yet another password.
4. I think the details of password length, password complexity and password history should not be fixed too precisely, because it really depends on the security policies of each organization. The main point in general is that in security policies, there must be rules for password length (a minimum length should be defined), password complexity (the minimum complexity of passwords should be described) and password history (the minimum number of old passwords to check should be defined).
5. I would not present managing the history of passwords as a "nice to have" feature, but rather as a mandatory feature.
How to avoid similar passwords?
In order to hinder users from using similar passwords or passwords with simple counters ("test1" -> "test2") it would be nice to implement the Levenshtein Distance for the change of passwords and only allow those with at least a minimum distance.
The problem with the distance function is that I need to know the old password, which I shouldn't. If I save passwords as hashes the function doesn't work anymore.
Is there already an algorithm to compare passwords without saving them as plain text? I can imagine something like a function that saves the structure of the phrase, i.e. "test1" consists of 4 alphabetical lowercase signs and one number - the same as in "test2". But also in "ak9Me". So it needs to be a bit more sophisticated.
Password lifetime criteria
Is there any advice or direction on how often a system should require a password to be changed?
Passwords that change too often are much less likely to be committed to memory, which leads to more use of the dreaded sticky note on the monitor. For instance, if a system typically has monthly access from users, and has a 90 day password change policy, this would lead to each password only being used ~3 times before requiring change.