Talk:Password length & complexity

Several proposals for addition into article:

1. Add threat model and a role of password complexity as possible mitigation:
   • Online guessing attacks
   • Offline guessing attacks
   • Breadth vs. targeted attacks
   • Relation between password storage and effectiveness of password policy[1]
2. Psychology acceptance issues
   • If account is important for a system (e.g. staff vs. customer accounts, privileged vs. unprivileged, etc).
   • If service is important for a user (e.g. personal backup vs. bulletin board vs. movie ranking site vs. banking service, etc).
   • Theoretical limit for memorable passwords entropy per user/site, per user/all sites he use.
   • Password entering usability concerns (mobiles vs. desktop).
   • Presence of multiple factors of AuthN.
3. Password policy implementations considerations
   • Preference length over "complexity" [link needed]
   • Gamification is a friend [link needed]
   • Heuristic-based over formal polices [2,3]
   • Known password blacklists
   • The pitfalls of "password strength meters"[2] (Luke Briner)
4. List of approved password polices
   • Strong polices: passwdqc, zxcvbn
   • Liberal polices?
   • libpathwell?
5. Other aspects of password policy
   • Password expiration (pros and cons) [links needed]
   • Password history (pros and cons)
   • Client-side vs server-side
6. Password generation
   • Link to entropy of random passwords on Wikipedia
   • Pronounceable passwords
7. Something else?

Btw, Wikipedia's Password Strength page is good enough but have no direct recommendations for developers. It is rather good compilation of different opinions and researches. At least links are very useful.

Materials:

• [1] An Administrator’s Guide to Internet Password Research by Dinei Florencio ˆ, Cormac Herley, and Paul C. van Oorschot
• [2] Your Password Complexity Requirements are Worthless by KoreLogic
• [3] Testing Password Polices by adedov@

--Adedov (talk) 06:05, 14 November 2015 (CST)

---

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?

The linked KoreLogic video considers this in a much more straight-forward manner. Based on research of NTLM hashes which are easy to crack, it was noticed that all a password policy does is to make people use a capitalised word, a couple of numbers and perhaps a punctuation mark e.g. Denver2014! and this massively reduces the amount of brute-forcing required. The suggestion is to blacklist certain patterns (or you could at least warn the user that their pattern is weak) such as ullllldds and ullllldddds etc. What you can also do with that approach is to not allow the user to have the same pattern twice in a row, which would prevent things like test1 -> test2.

It is not in use anywhere obvious on the web but is based on the latest real-world threat model from hackers. --Luke Briner (talk) 11:38, 16 November 2015 (UTC)

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

Not that much hard and fast direction (is there ever?)

The question is about the threat model that password changing is supposed to prevent. Firstly, it can help mitigate using the same password across multiple web sites since passwords wouldn't all change at the same time. Secondly, it would require an attacker to crack a password within the password change frequency in order to make use of it (this is based on certain assumptions such as not changing password1 to password2 and the fact that the user has not used the password elsewhere in which case you are only as safe as the least safe site!). I used to work for a very large security company and their (corporate) policy required a change every 3 months. I think they assumed that the chances of a leak were fairly low with all their other measures in place. I'm also sure that plenty of people would say that there is no major value in the policy since unless you use a password manager, it becomes almost impossible to manage and if you do, you might as well just generate such a strong and unique password that it is unlikely to be cracked and won't be shared anywhere else which means there is no point changing it! --Luke Briner (talk) 11:22, 16 November 2015 (UTC)