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.
