Keeping the password 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. For example: the client expects IT Services to prevent other individuals from accessing resources using the client's 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 (who would then look elsewhere for their requirements), and would require SPs to provide their own access management systems (tending towards a fragmented approach to IT provision rather than a unified/federated approach - clients could expect to have a different username/password for each service, with local policies on complexity, expiry, etc).
At a University-wide level it seems 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 at the IT Services Help Desk by users, and web searches show that the issue crops up all over the world 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.
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.
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, provided through some sort of web form and, for an increasing number of banks, using an additional device such as a card reader. If you use several banks then you might 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.
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).
Chip-and-PIN is widespread now, and PINs do not expire. Why? This is a classic example of two-factor authentication: you need to have the card and know the PIN. As and when two-factor (or the more general case of multi-factor) authentication becomes available within Oxford then this is likely to also use permanent secrets.
4.4. Expiry was designed to thwart cracking tools, 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 arguably 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 over the network, and others are collected by phishing schemes. This is not an argument against password expiry though - it is simply a recognition of the fact that password expiry is not the complete solution to password compromise on its own.
Users who remember to change their password regularly won't get these messages. We do try to word them carefully, to avoid the flaws typical of fake emails.
Lots of users do write their password down and knowingly 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 a virus, vulnerability, or social engineering trick.
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, so the expiry policy can't be the underlying cause.
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.
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.
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.
Such an incident occurred in 2009. With a password expiry system in place it was felt that the risks were satisfactorily managed by using expedited password expiry for users known to be affected and standard password expiry to render useless those passwords possibly exposed over the following months. Without an existing password expiry system, it may have been considered necessary either to introduce one or to force more disruptive immediate password resets upon a large number of users.
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 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.
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.
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.