1. Why is password expiry necessary?
Keeping passwords safe is a key factor in the overall security of an individual's digital identity, and consequently the services and resources to which that identity has been granted access. Access management services, such as those provided by IT Services, are involved in bringing together the individual (client) and provider of services and/or resources (SP). In this arrangement IT Services acts as an arbiter between the two parties, and is involved in assuring a level of security to each. The client expects IT Services to prevent other individuals from accessing resources using their identity; the SP expects IT Services to ensure that clients are properly authenticated in order to adequately control access to their services and resources.
This model means that IT Services must manage the access management infrastructure in such as way that it can meet the common requirements of both clients and SPs. Failure to offer the required levels of assurance would undermine the trust placed in IT Services by clients, and would require SPs to provide their own access management systems.
At a University-wide level it is desirable to maintain and use a central access management infrastructure which offers both simplicity to the client (single username, password, with a single registration procedure and uniform guarantee of identity security), and removes the burden of identity management from the many individual SPs. This requires us to define a policy for password management that assures clients and service providers alike that IT Services is taking adequate steps to maintain overall security of clients' digital identities.
Password expiry is a topic that typically evokes strong responses wherever it is discussed. There have been many internal debates at IT Services, it is a common subject raised by users, and web searches show that the issue crops up in many different types of organisation. Despite the general acceptance of other password security measures, password expiry is typically viewed as necessary by those responsible for ensuring security, and inconvenient by users.
There are two processes that result in password expiry at Oxford. The first process uses manual password expiry to force a password change when it is suspected that a password has been exposed to someone other than the account owner. The second is the automated process of periodic password expiry. While the latter cannot reduce the occurence of password compromise, it limits the potential for abuse of compromised passwords to a specific time period.
This might seem strange when set against the backdrop of a huge number of everyday web sites/services that authenticate visitors but which do not implement password expiry. We are often asked to justify our policy in the light of what appears to be common practice – some of the most frequently presented arguments appear below.
2. Challenges to Password Expiry
2.1. Online banking
Authentication to online banking services is typically done using something more complex than simple username/password. In most cases you are sent a user ID, and agree some secret in advance with your bank. You are then asked for your ID and a subset of the agreed secret information. Increasingly, banks require the generation of a one-time password on a card reader (in effect this is a password with a very short lifetime). If you use several banks then you will have several IDs, several secrets, and several card readers. This kind of technology works well for a single web site, but doesn't readily transfer to email clients, desktop login, network file access, and so on.
2.2. Google Mail, Facebook, ...
There are lots of web sites where you login with a non-expiring password, and may even then upload information that you intend to keep private. If your password is compromised then you stand to lose the security of any information held in your account, and an attacker may then go on to perform actions using your identity (if your email account is compromised then an attacker can typically use this to reset passwords on other sites that you use too). The key issue here is that the web site is typically only providing you with one service, so apart from the impact on their reputation and possible loss of a (non-paying) customer, they stand to lose very little. In contrast, Oxford University provides a wide range of services that would fall prey to a password compromise, and parts of the organisation place a lot of trust on the integrity of these services, so there is potential for large ramifications (think of the simple case of a student who cannot submit their essay because they cannot access their network file store).
2.3. Bank card + PIN
Chip-and-PIN is a classic example of two-factor authentication: you need to have the card and know the PIN, so there is no need for the PIN to expire.
2.4. Expiry was designed to thwart crackers, but passwords can be found and used within minutes now
One of the few recorded reasons for setting password expiry policies is that in the 1970's, government computers could attempt all possible combinations of a password within about 90 days. So password expiry was introduced and set to 90 days in order to thwart this. Gains in computer speeds have outstripped increases in password and algorithm complexity, but have also become largely irrelevant - many passwords are simply read off a user's PC after it has been compromised, and others are collected by phishing schemes. This is not an argument against password expiry; it is simply a recognition of the fact that password expiry is only part of the solution of keeping passwords secure.
2.5. Password expiry notifications look like phishing emails
Users who remember to change their password regularly won't get password expiry warnings. We do try to word them carefully, to avoid the flaws typical of fake emails.
2.6. Forcing users to change their password on expiry just means they write it down
Lots of users do write their password down and keep it where other people might readily discover it. Still more type their password into programs that store it on their computer - unknown to the user, but readily accessible to an attacker who gains access to their PC via malware, a vulnerability, or social engineering.
In fact it's often the complexity requirements that lead to writing the password down - people write their password on a post-it before they are even aware that there is an expiry policy.
3. Benefits of Password Expiry
3.1. Stolen passwords expire
OxCERT have come across cases where an account has been compromised without the owner spotting that it is being used by someone else, sometimes over a period of several months. It is likely that many incidents go undetected and abuse of accounts only ceases upon password expiry. Additionally, compromised accounts are not always used immediately following the breach - so password expiry can reduce the window of opportunity for the buyer of stolen Oxford account details.
3.2. Reduce chance of password export
How many people make sure that all their passwords are deleted from a computer sold or sent for repair/recycling? Old machines that are poorly maintained are classic targets for network attack - maybe a PC that has been handed from parent to child (or vice versa these days) or from recycling scheme to hard-up student - and could well have lots of old passwords cached in the email settings, web browser cache, personal keystore, and so on. Password expiry is effective in many of these cases as the timescales involved are comparable, particularly as there is often a delay between decommissioning and disposal of old systems.
3.3. Risk management in unusual incidents
In many incidents, the risk of abuse as a result of password disclosure is high, and an immediate password change is required. In other cases, the risks are relatively low but non-zero, and may increase slowly over time. Some incidents of this nature may occur relatively frequently but may affect a large proportion of users.
3.4. Reduce cross-system compromise
It is quite common for new users to set a preferred password on all the systems they will access, leading to two problems. Firstly that one of the systems may well store the password in a weaker form that is more readily compromised. Secondly that compromise of the password on one system (possibly the weakest) immediately compromises account security on the other systems where the user has chosen the same password.
Password expiry (especially when combined with non-reuse complexity) tends to encourage selection of different passwords for different systems.
Password expiry cannot prevent disclosure of passwords as a result of malicious or flawed software. When these problems are identified by OxCERT it is necessary to ensure that users change their passwords as soon as possible. Through password expiry, users are likely to be familiar with our password-changing mechanisms and procedures.
3.6. Technical benefits
Requiring users to set a new password on a regular basis means that changes to the underlying systems can be rolled out transparently. Rekeying (eg. encryption of the typed password with new, stronger algorithms), changes in complexity requirements, and refresh/propagation/resynchronisation of details across systems can all take place without needing to carry out an explicit user campaign.
4. Why once a year?
The expiry period is a balance between short which (all else being equal) best satisfies the necessity of those providing an assurance of security, and long which is of least inconvenience to users.
Auditors seem to recommend 30-day, 60-day, or 90-day expiry for business systems (most Oxford SSO accounts can be used to access at least one business system such as the student records system, OxCORT, or GSS). We feel that this is towards the short end of common practice and is likely to introduce negative effects such as significant amounts of staff time used up in changing/resetting passwords, weaker passwords (eg. pattern-based, short, or simple), and increased writing down of passwords.
In our view, choosing an expiry period that roughly matches business cycles (in our case annual) quantitatively offers a sensible mid-point where improved assurance of security is realised without overburdening users with password management.