Is Pavlovian Password Management The Answer?

Posted by: Lance James   May 1, 2014 23:4617 comments

Something hit me straight in the face that may be a method for inducing cognitive awareness to end users in regards to password management. Ironically this also has a side effect of scalability when managing password changes. It isn’t completely flushed out but I wouldn’t mind getting some opinions on this. I am thinking of prototyping this in a PAM module in my spare time.

Lance James, Deloitte & Touche LLP

Lance James, the head of Cyber Intelligence at Deloitte & Touche LLP offers some thoughts on a system to improve the quality of user passwords.

Here goes…

For end users we have been trying to get users to understand the importance of constructing good passwords. We provide guidance on what a good password is (even though the guidance that I have seen is still usually unacceptable in most places when compared to NIST guidelines).

We spend a lot of time telling the user to “do this because security experts advise it, or it’s part of our policy” but we don’t really provide an incentive or an understanding of why we tell them to do this. Well humans are programmable, and the best way to see the human brain is to look at it like a Bayesian network. It requires training for it to adapt to change, and repeated consistent data to be provided. Gmail and LinkedIn and the likes all offer 2-factor authentication but the percentage of adoption is low.

One thing I’ve learned about humans is that in most cases, they will take the path of least resistance when it comes to change management, and only when applied pressure (road block is a nice way of putting it) or a reward is offered does this usually disrupt this path.


  • Assume a good password storage system such as SRP has been implemented
  • Assume a detailed understanding of the guidelines are provided for password security
  • Assume we also provide help tools such as password generators etc
  • Assume lower bounds will be decided by the CISO and they will not allow empty or bad passwords.

Password Complexity and Choice:

When looking at password choices we include multiple factors which encompass “risk” — some include:

  1. Complexity
  2. Cost
  3. Time

So let’s divide this into Cost & Time. For example: a user is asked to set up a password (this could also be on a known popular service like Gmail and in that case it’s a change of password). The user types in password: test123@# (this is pure hypothetical example excluding rainbow tables) In a case like this the probabilities for offline cracking are approximately 4.5 days before success. (I used GRC haystack for this example, it’s hypothetical and not what I would consider the true basis for all the variables necessary.)

Dog being rewarded

Can we improve users’ choice of passwords with more disciplined password management?

[Read more Security Ledger coverage of issues related to password insecurity here.]

We will allow this, but let the user know the cost and value of the password, including it’s time for success — this doesn’t even include rainbow tables yet — but that is another variable.

Response to password:

Thank you for your password, your password will expire in 3 days. The user in three days will be asked to provide a new password:

Three days later:

Password_Change_Request: t3st123@##$x

Offline cracking: 37.58 Centuries
Distributed Cracking: 3.76 years

We will ask you for a new password in 3 months.*

Example payment schedule:

Strength       |    Expiration

Weak             |    3 days

Medium        |    2 weeks

Strong           |   60 days

Passphrase  |  90 days

Now of course, sysadmins/ciso’s can set their lower bound allowances since there are other variables to consider, but the point here is to provide an incentive of payment. If a user wants to use the system, and limit the annoyance of being asked for a password in short amounts of time, we will train the user by having his payment be a better password to increase his time before the next expected password change. The least amount of effort and cognitive awareness during this
process will likely cost you more in effort in the long run, and force cognitive awareness, whereas if performed correctly the first time, less cognitive load will be required on the user in the long run, and a more secure environment will be presented to the user experience.

Keep in mind there are many variables I am not including yet — but this would be very easy to make a PAM module on the backend accompanied by an interactive front-end and it will automatically induce better behavior and an altered mind-set regarding password management.

Now the values on the backend on a global scale also allow a measurement of change over time — you can literally watch the success rate from the beginning. Literally the evolution of change will be
measurable, and you will identify some key perspectives:

  • Percentage of initial least-effort passwords
  • Percentage of initial secure passwords
  • Success of change (temporal and density)
  • Overall failure rate (minimal deviation of least effort passwords over time)
  • Overall success rate (percentage of deviation of secure passwords over time)

This can be used to fine tune the program. Keep in mind expiration does not have to be the only incentive since the points between successful strong password and acceptable minimum bounds is quite small but it is an incentive I chose to use as an example.

Other Advantages:

Could scale password changes over time, since they won’t have to be done at the same time, also reducing predictability and making expiration/changes dependent upon the user. Could be also turned into a form of a game such as earning badges for “strongest password of the month”, or “top 10 security conscious users this week”.

Thoughts, queries, bashes, etc?


(*)Please don’t associate password expiration with true time to crack, rather consider it a configurable setting that is designed to condition a response from the user.



  • Soren Maigaard

    Interesting idea.
    I considered creating (relatively easy to remember, hard to crack) pass phrases for our users (because users are inherently bad at picking good passwords) and then not asking for password resets unless we have a reason to. That way the users could avoid even the 90 day rule as a benefit for using a passphrase we know to be strong.
    The question is if auditors will allow this policy where we only change passwords when needed (intrusions, detected social engineering etc) instead of on a regular schedule.

  • Great idea! This immediately inspired me to write some further thoughts on this:

  • Where’s my comment? Doesn’t fit your agenda, so not approved??? Will try again…

    • OK, it looks like my earlier comment is in moderation because it contains a URL… Will try again (you can edit the URL into my comment later if you wish)…

      • yes – sorry for the delay. i’ve tweaked the settings to prevent a single URL from resulting in a flagged comment, Matt. thanks for your great comments.

  • This is not an original idea — but one I published over three years ago, which was discussed in a section of the security engineering community at the time! Still, I appreciate your popularising a good idea! I would guess that the reason we both appear to have had similar ideas is because there is a need for this technique which is obvious to anyone sufficiently acquainted with the art.
    Search Google for “Preventing reuse of passwords” and you will find my article…
    Note the sentence under my point 3, “Values and limits for a, p, LMAX / p may vary according to administrative discretion and the strength of the selected password.”
    My system not only considers password strength metrics, but also considers the variation of password expiration date according to other simultaneous priorities such as the prevention of cross-site password reuse.

  • presumably the ‘spring1’ ‘spring2’ ‘spring3’ user would realize that their insistence on using weak passwords was creating more work for them, right?

    • They should realise that, eventually; especially if the user-interface was ergonomically designed, as per Sampo’s design. This underlines the more general point that ergonomics are an essential component of system security — which is obvious when you consider how often end-users are the weak link!

  • Anything that slows down the bad guys is a good thing! Hashing techniques are important. If your choice of hash algo means the bad guys can only guess 1–10% of your passwords before they’re reset, rather than 50–95% of them; this is a good thing!

    However I agree with your broader premise that one or two extra techniques are never going to constitute a magic wand that fixes all your security problems!
    The behaviour demonstrated by your boss 20 years ago (incrementing a counter on his password) is very common indeed. I’ve thought about this problem and personally I think that the best ways to fix that problem are:
    * Implement my system for discouraging cross-site password reuse, and use “strict policy” constants to calibrate the rate of changing passwords
    * Implement very smart password strength metrics, informed by password cracking efforts (public sources of cracked password databases) — for a start, find any dictionary words, keyboard runs, contiguous streams of the same kinds of characters, common patterns (or anything resembling them) within a new password before hashing it, and mark down the strength score accordingly using an information-theory and statistics based approach.
    Most importantly, if you want a really strong system:
    * Don’t even allow users to specify 100% of their password plain-text! Let them specify part of it, but append a number of random characters to the beginning/end of their password, part of which the end-user might be allowed to write down on a piece of paper and keep in their wallet.

    • Steve Sether

      There’s a few techniques that can very easily increase the computational complexity.

      1. Randomly salt every password with at least 128 bits of entropy.
      This prevents rainbow table attacks on passwords.
      2. Choose a good hash algorithm that hasn’t been broken. SHA-512 is a good choice.
      3. Take the output of your hash algorithm, and hash it again. Repeat many thousands or millions of times.
      4. Optimize your code, or get highly optimized code so you can run as many iterations as possible in step 3.

      It’s very simple, and I’m surprised more people don’t do it. It’s a hell of a lot better than getting users to play this strange game of increasing the entropy of their passwords (which naturally decreases the chance they’ll remember the damn thing, and also increases the chance they’ll re-use the thing somewhere else). If you have a 100,000 iterations of your hash algorithm, that’s 100,000 less password guesses/second that an attacker can run against a breach of your hashes.

  • John Kula

    A couple quick points Lance…

    1) On the assumption SRP is in place, a brute force against the password database (assuming the attacker can even get their hands on it) is greatly increased over what is common practice today. I’m not sure a few characters here or there really increase the work effort of the attacker substantially. SRP has the added bonus of making it a pain to data mine passwords with today’s bots. No more having an easy time just pulling the post, instead they fall back to raw keystroke logging which makes data mining that much harder.

    2) Studies have show, Carnegie Mellon has done some good research here, that most users will just append a single digit to a password, and force changes are not helpful to security. It seems that basic password strength meters do more to increase password strength (as long as they are tough graders) and seem to have no impact on users remembering the stronger password.

    It seems security continues to be focused on the wrong issue. Brute forcing from the client side isn’t the issue, bots lifting clients credentials, and companies poorly storing & transmitting the credentials are.

  • Mance Harmon

    Hi Lance,

    While on the surface this sounds like a reasonable thing to do, I think the logic is flawed in several ways…

    First, primarily, it’s a straw-man argument… It’s not reasonable to assume that an attacker won’t use a dictionary attack (rainbow tables). If an attacker uses rainbow tables, then the whole approach falls apart.

    If we assume that an attacker can get access to the password file in the first place, then we have to assume that they can get access every day. If that is the case, then we shouldn’t be allowing anybody to use insecure passwords, even for a single day, because a dictionary attack will work against some of those passwords. And if it doesn’t work the first day, then an attacker will just try again each day until it does work.

    If we worry less that somebody can steal our password file, but rather the real concern is social engineering or duplication (from a sticky note), then we shouldn’t require an onerous password policy. In that case, we should let users choose passwords that are simpler to remember, but require frequent rotation. This mitigates these attacks.

    Then, there is another problem with this logic. Even if we accept the stated premise that we won’t consider the use of dictionary attacks, the unstated premise is that an attacker will brute force a password for a single user for 3 days or longer. In practice, that isn’t what happens. Attackers will run their cracking tool against the entire database of users for some period of time, but not for 3 days on a single user. If we are worried about an attacker targeting a specific user for 3 days in a brute force attack, then we should be requiring strong auth for that specific user. If we are legitimately worried about targeted attacks, then the rules for those individuals should be different than for the norm. The company should have considered that some of its employees have access to high-value resources, and require stricter authN for that group. If we are worried that an attacker will choose a random identity and try to brute force the password, then we need strong auth for every employee, and we should never allow less secure passwords.

    So, in summary:

    1) if we aren’t worried about our password file being stolen, but instead are worried about passwords being compromised in other ways, then we should require passwords that are easier to remember (and less likely to be written down), and then rotate them more frequently.

    2) if we are worried about a targeted attack against a group of individuals, then we should require strong auth for those identities.

    I can’t think of a reason why we would every allow people to use less secure passwords for even 24 hours, but then encourage them to use stronger passwords. It’s hard to imagine a threat model for which that is the best mitigation policy.

  • Dracolith

    Careful with making it a game “strongest password of the month” is just inviting attackers, as this incentivizes them with potential bragging rights — if they compromise “the most ‘secure’ user”. Only do that if you’ve taken steps to ensure that login usernames and user e-mail addresses are not learnable, for sure.

  • Joseph Tag,Jr.

    I continue to like older United States licence plates of family cars. My “circle of friends coworkers family” doesn’t know; clueless about pssword choice. A password of zygxa9g may be hard to discover. I like additives as Key to SSN last 4 digits; I.e. 2020 . Joe Tag.

  • Today this is not possible to implement such a solution on LDAP/AD. So I guess you’ve to do it through an internal web portal. This website must have an access to the password to check its complexity. This means your password is sent in plain text to this website or at least it has the key to decrypt it, this means symmetrical encryption with key loaded in this server’s RAM. Moreover this solution does not answer the main security problem: passwords can be found VERY easily on every computer or server. So the main requirement is to change them the most often you can. I greatly prefer to have a medium password you’ll change often than a passphrase you’ll change once a year.

%d bloggers like this: