This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Talk:Password length & complexity"

From OWASP
Jump to: navigation, search
(Added talk comment about password lifetime criteria)
Line 22: Line 22:
  
 
Any ideas?
 
Any ideas?
 +
 +
== 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.
 +
 +
Dave Elton

Revision as of 13:22, 14 November 2008

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.

Philippe Curmin

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.

Any ideas?

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.

Dave Elton