In October 2016, UCL’s Information Services Division (ISD) implemented a new password policy to encourage users to choose stronger passwords. The policy links password lifetime (the time before the password expires) to password strength: The stronger the password, the longer the lifetime.
We (Ingolf Becker, Simon Parkin and M. Angela Sasse) decided to collaborate with the Information Services Division to study the effect of this policy change, and the results were published at USENIX Security this week. We find that users appreciate the choice and respond to the policy by choosing stronger passwords when changing passwords. Even after 16 months the mean password lifetime at UCL continues to increase, yet stronger passwords also lead to more password resets.
The new policy
In the new policy, passwords with Shannon Information Entropy of 50 bits receive a lifetime of 100 days, and passwords with 120 bits receive a lifetime of 350 days:
Additionally, the new policy penalises the lifetime of passwords containing words from a large dictionary.
Users play the game
We analysed the password lifetime – what we will refer to from here on in as the ‘password strength’ – of all password change and reset events of all pseudonymised users at UCL. The following figure shows the mean password expiration of all users over time, smoothed by 31-day moving averages:
A small drop in password strength was observed between November ’16 and February ’17, as users were moved on to and generally became accustomed to the new system; the kinds of passwords they would have been used to using were at that point not getting them as many days as before (hence the drop). After February ’17, the mean strength increases from 145 days to 170 days in 12 months – an increase of 6.9 bits of entropy. This strongly suggests that users have generally adapted slowly to the new password policy, and eventually make use of the relatively new ability to increase password lifetime by expanding and strengthening their passwords.
The evolution of the mean password strength is underpinned by cyclical behaviours. A quarter of users have a password lifetime of less than 110 days and have to change their passwords on average every 80 days, but every time they do, they increase their average password strength.
This manifests twice in this figure: at the start of the deployment of the new system where there are no existing users (the increase in password strength is delayed until February ’17); and again, with the enrolment of over 10,000 new students who set their first password around September ’17, in time for the start of the new academic year. As this large number of users have all set their initial passwords in a short time frame, their first regular password change occurs from November ’17 onwards.
Changes and Resets
Over the 16 months of data collected, we observe that 66% of users had to reset their passwords. On average, there are 1.1 resets per user, and 2.4 changes per user. There is a strong positive correlation between password strength and likelihood of reset before expiration: A user with 300 days lifetime is 4 times as likely to forget their password than a user with a lifetime of 100 days.
Also, the more times a user resets a password, the weaker their password choices.
In the figure above we plot the average password lifetime of unexpired passwords grouped by the number of password resets a user has performed. While the average password lifetime of all groups is increasing as the users renew their password, the division between users with 0 or 1 resets and users with more resets is pronounced, separated by at least 10 days of lifetime.
This analysis suggests that one reset per year does not affect the system’s performance, but two or more resets do (which applies to 27% of users).
The effect of expiration warnings
At UCL, we are sent a reminder of a password’s impending expiration 5 times: 30, 20, 10, 4 and 1 day(s) in advance. The following figure plots the frequency of password changes and resets relative to the time of password expiration:
Every time users receive an expiration reminder, approximately 10% of all users act upon the reminder and change their password within 24 hours. This implies that users on average change their password 22 days before expiration. Essentially the frequent reminders causes users to voluntarily reduce the lifetime of their passwords.
A useful policy?
The intervention was clearly successful: users – of all user groups – have been choosing stronger passwords in return for longer lifetime. However, from a cost-benefit analysis the intervention is counterproductive: All passwords at UCL fall into what Florencio et al. call the ‘Don’t care region of password strength’ wherein any increase in password strength provides no additional security. The weakest possible password (100 days) is strong enough to resist an online attack; while the strongest possible password (350 days) is not strong enough to resist an offline attack. This ought to be considered alongside an increase in costs to the user to memorise and use more complex passwords. We also observed that stronger passwords cause a higher reset frequency, which increases interactions with online self-help and helpdesk support.
In light of this analysis, one argument could be that this policy is useful when it encourages users to choose passwords that are ‘usefully stronger’, giving a limited lifetime to passwords weaker than the online guessing threshold (or some other threshold that is supported by threat models) and removing expiration of passwords beyond that threshold, in line with current guidance. We have continued to have productive discussions on the password system and authentication management with UCL’s ISD since completing the analysis.
Further details can be found in the full paper: “The Rewards and Costs of Stronger Passwords in a University: Linking Password Lifetime to Strength”.
This is fascinating and much-needed work! A couple of suggestions for follow-up work:
* It appears from the paper that only Shannon entropy was used to measure password complexity – though the paper also explicitly mentions zxcvbn and other efforts and acknowledge that Shannon entropy is insufficient to gauge offline cracking resistance. Are there plans to expand the strength checking to include zxcvbn, checking common masks, well-known leaked passwords, etc.?
* While difficult to arrange with one’s IRB, I’d love to see follow-up statistics on the real-world “crackability” of these passwords – resistance to actual cracking. Ideally, this would be in consultation with fellow academics or practitioners with specific real-world cracking experience.
* I’d love to see more information on the UX – how the users are interactively guided into increasing the entropy of their passwords.
* I’d also love to see an expansion of the initial UX and messaging to your users, to include information on how to generate and use random passphrases (which have higher classic Shannon entropy, higher rates of memorization success, and significantly higher resistance to real-world cracking). Ideally, I’d love to see the real-world “crackability” statistics captured before and after this change.
Great work!
Thank you for the comments Royce.
A move to zxcvbn would be great – (although zxcvbn is only really interested in accurately estimating the password strength of weak (<104 guesses) passwords with the default of 234kB of data).
Regarding you comment on the real-world crackability of these passwords: I think this has been sufficiently established [see Section 2.3 in the paper], and I am not sure another study would contribute much.
The only feedback they get is the expiration (in days) of their passwords, updated on every modification to the new password.
I think what is more important though is recognising that it is not the users job to protect their password from an offline attack – this is ISD’s job, and they have got a lot more tools to their disposal than users do (e.g., advanced password hashing, password database encrpytion).
Now, this depends on ISD’s definition on when a password is sufficiently strong: and that will depend on their defences (such as, as you mentioned, by checking against leaked password databases, by throttling login attempts, and by proactive monitoring). Once a user’s password is stronger than this threshold, passwords should only be expired if there is evidence of password compromise (see NCSC guidance, linked above).
Demanding that users increase their password strength just for the sake of it is not reasonable.