Pavlovian Password Management Protocol

A proposed experiment for conditioning better password choices.

Hi all,

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.

—here goes

Intro:

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 auth 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.

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:

Scenario 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.

(Used GRC haystack for this example, it’s hypothetical and not what I

would consider the true basis for all the variables necessary)

So 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:

3 days arrives:

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.

[Caveat: 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]

example payment schedule:

Strength | Expiration

——————————-

weak | 3 days

medium | 2 weeks

strong | 60 days

passphrase | 90 days etc

——————————-

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:

1) Percentage of initial least-effort passwords

2) Percentage of initial secure passwords

3) Success of change (temporal and density)

4) Overall failure rate (minimal deviation of least effort passwords

over time)

5) 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?

Thanks!

Assumptions:

Assume a good password storage system such as SRP has been

implemented: http://srp.stanford.edu

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.