Single sign-on password expiry

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 websites and 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.

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.

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.

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.

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.

Familiarity

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.

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 (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.

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 the 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 (too simple, short or pattern-based), 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.