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…
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.
Assumptions:
- 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:
- Complexity
- Cost
- 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.)
[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?
Thanks!
(*)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.