Passwords in online services

At a glance

• Although the UK GDPR does not say anything specific about passwords, you are required to process personal data securely by means of appropriate technical and organisational measures.
• Passwords are a commonly-used means of protecting access to systems that process personal data. Therefore, any password setup that you implement must be appropriate to the particular circumstances of this processing.
• You should consider whether there are any better alternatives to using passwords.
• Any password system you deploy must protect against theft of stored passwords and ‘brute-force’ or guessing attacks.
• There are a number of additional considerations you will need to take account of when designing your password system, such as the use of an appropriate hashing algorithm to store your passwords, protecting the means by which users enter their passwords, defending against common attacks and the use of two-factor authentication.

In brief

• What is this guidance about?
• What is required under the UK GDPR?
• What else do we need to do?
• What are the challenges in choosing the right authentication scheme?
• Are passwords the best choice?
• What makes a secure and useable password system?
• What should we consider when implementing a password system?
• How should we store passwords?
• How should our users enter their passwords?
• What requirements should we set for user passwords?
• What should we do about password expirations and resets?
• What defences can we put in place against attacks?
• What else do we need to consider?

What is this guidance about?

This guidance is intended for use when you want to implement a password-based authentication scheme for an online service. It outlines the considerations that you should have where your authentication scheme will be protecting access to personal data.

Using passwords or other credentials for your internal network and information systems are out of scope of this guidance. However, there may be content that applies in this context all the same.

Before reading and applying this guidance, you should consider whether passwords are the most appropriate method of authenticating users, or whether other alternatives will provide more security and less friction for users.

What is required under the UK GDPR?

The UK GDPR does not say anything specific about passwords. However, Article 5(1)(f) states that personal data shall be:

‘Processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures’

This is the UK GDPR’s ‘integrity and confidentiality’ principle, or, more simply, the ‘security’ principle. So, although there are no provisions on passwords, the security principle requires you to take appropriate technical and organisational measures to prevent unauthorised processing of personal data you hold.

This means that when you are considering a password setup to protect access to a system that processes personal data, that setup must be ‘appropriate’.

Although the UK GDPR does not define what is ‘appropriate’, it does provide further considerations in Article 32, ‘security of processing’:

‘Taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.’

This means that when considering any measures, you can consider the state of technological development and the cost of implementation – but the measures themselves must ensure a level of security appropriate to the nature of the data being protected and the harm that could be caused by unauthorised access.

In other words, you cannot simply set up a password system and then forget about it – there must be a periodic review process.

What else do we need to do?

You must ensure that you are aware of the state of technological development in this area and that your processes and technologies are robust against evolving threats.

For example, advances in processing power can reduce the effectiveness of cryptography or particular design choices can become outdated.

You must also consider whether there might be better alternatives to passwords that can be used to secure a system.

Article 25 of the UK GDPR also requires you to adopt a data protection by design approach. This means that whenever you develop systems and services that are involved in your processing, you should ensure that you take account of data protection considerations at the initial design stage and throughout the lifecycle. This applies to any password system you intend to use.

At the same time, provided you properly implement a password system, it can be an element that can be used to demonstrate compliance with your obligations under data protection by design.

What are the challenges in choosing the right authentication scheme?

One of the biggest challenges you face when dealing with personal data online is ensuring that such data can be accessed only by those with the correct permissions - in other words, authenticating, and authorising, the individual who is trying to gain access.

It is commonly accepted that there are three main ways of authenticating people to a system – checking for:

• something the individual has (such as a smart card);
• something the individual is (this is usually a biometric measure, such as a fingerprint); or
• something the individual knows.

Of these, the most commonly used is something the individual knows. In most cases something they know is taken to be a password.

Passwords remain the most popular way that individuals authenticate to online services. The reason for this is that a password is generally the simplest method to deploy and the most familiar for individuals.

Despite this, passwords carry well-known risks. The biggest risk is that people passwords as a mathematical problem that can be solved by increasing complexity rules. This fails to take into account natural human behaviour which is to make passwords more easily memorable, regardless of the cost to security.

A rigid focus on password strength rules with no consideration of the usual behaviour of people choosing passwords means that you can make inappropriate choices in setting up and maintaining of your authentication system. This could place the wider security of your systems or your users at risk, and could lead to unauthorised or unlawful access to personal data.

Are passwords the best choice?

The success of using a password to properly authenticate a user of your service relies on the fact that their password remains a shared secret between you and them. When a password is shared amongst users or can be easily guessed by an attacker it can become extremely difficult to tell the difference between an authorised user and an imposter with stolen or guessed credentials.

The proliferation of online services requiring individuals to create an account has created a risk that people become overwhelmed with access credentials and default to reusing a short and memorable password (often coupled with the same email address as a username) across multiple websites.

The risk here is that if one service suffers a personal data breach and access credentials are compromised, these can be tested against other online services to gain access – a technique known as ‘credential stuffing’.

Before designing and implementing a new password system, you should consider whether it is necessary to do so, or whether there is a better alternative that can provide secure access.

One common alternative to building your own solution is to utilise a single sign on (SSO) system. While this has its advantages (not least a reduction in the number of passwords that a user has to remember) you must ensure that you are happy with the level of security that is offered by that system. You should ensure that you have a documented record of the considerations you made when reaching this decision.

You must also consider what will happen if the SSO is compromised, as this will most likely result in your user’s accounts also being compromised.

What makes a secure and useable password system?

A good password system is one that provides you with sufficient assurance that the individual attempting to log in is the user they claim to be. In practice, this means a good password system should protect against two types of attack:

• firstly, it should be as difficult as possible for attackers to access stored passwords in a useable form; and
• secondly, it should protect against attackers trying to brute force or guess a valid password and username combination.

Your system should also make it as easy as possible for users to create secure and unique passwords that they can remember or store easily. It should not place an undue burden on individuals to make sure that their account is secure. Putting such barriers in place can result in users making less secure password choices.

The advice provided in this guidance is a good starting point for most systems where personal data is being protected. It will be updated as necessary, but you should consider whether you need to apply a higher level of security given your particular circumstances.

This will largely depend on the nature, scope, context and purposes of your processing and the risks it poses. However, in essence, the more serious the consequences of a compromise, the higher the level of security that you will require.

You should ensure that you stay up to date with the current capabilities of attackers who might try to compromise password systems. You should also consider advice from other sources, such as the National Cyber Security Centre (NCSC) and GetSafeOnline.

What should we consider when implementing a password system?

If you are going to put in place a password system, you should take account of factors like:

• how you will process user passwords;
• how your users enter their passwords;
• the requirements you set for user passwords;
• what you do about password expirations and resets;
• the defences you put in place against attacks; and
• any additional considerations.

How should we store passwords?

Do not store passwords in plaintext - make sure you use a suitable hashing algorithm, or another mechanism that offers an equivalent level of protection against an attacker deriving the original password.

Well-known hashing algorithms such as MD5 and SHA1 are not suitable for hashing passwords. Both algorithms have known security weaknesses which can be exploited, and you should not use these for password protection in any circumstances. The biggest weakness with these algorithms is the speed that hashes can be calculated.

You should also consider avoiding other fast algorithms. Use a hashing algorithm that has been specifically designed for passwords, such as bcrypt, scrypt or PBKDF2, with a salt of appropriate length.

It is important that you review the hashing algorithms you use, as over time they can become outdated. Guidance on algorithms is available from a number of organisations such as the NCSC, the National Institute of Standards in Technology (NIST) and the European Union Agency for Cybersecurity (ENISA). You should also be aware of any sector-specific guidelines that are available and may be applicable to you.

You should make sure that you can replace any algorithm that becomes obsolete.

You should also ensure that the architecture around your password system does not allow for any inadvertent leaking of passwords in plaintext.

How should our users enter their passwords?

You should ensure that your login pages are protected with HTTPS, or some other equivalent level of protection. Failure to do so will mean that anyone who is in a position to intercept network traffic can obtain passwords and may be able to carry out replay attacks. You should also consider that browsers now mark pages that require secure input (such as login pages) as insecure if they are delivered over HTTP, and many browsers now mark all pages delivered over HTTP as insecure.

Make sure that password hashing is carried out server-side, rather than client-side. Hashing client-side will remove the protection afforded by hashing in the first place, unless other mitigations are put in place. This is a complicated area with a number of factors to consider. At the most basic level, if you are hashing client-side and an attacker obtains your password database, then those hashes can be presented directly to the server for a successful login.

Also, you should not prevent users from pasting passwords into the password field. Preventing pasting is often seen as a security measure, but at the same time doing so can impede people from using password managers effectively. The NCSC’s position on password pasting is the same, as expressed in this blog post discussing this issue in much more detail. Any attacks that are facilitated by allowing pasting can be defended against with proper rate limiting (see below for more details on rate limiting).

What requirements should we set for user passwords?

There are three general requirements for any password system that you will need to consider:

• password length - you should set a suitable minimum password length (this should be no less than 10 characters), but not a maximum length. If you are correctly hashing your passwords, then the output should be the same length for every password, and therefore the only limit to password length should be the way your website is coded. If you absolutely must set a maximum length due to the limitations of your website code, then tell users what it is before they try to enter a password. The reasoning behind having a maximum length should be documented and fully risk assessed;
• special characters - you should allow the use of special characters, but don’t mandate it. If you must disallow special characters (or spaces) make sure this is made clear before the user creates their password; and
• password ‘deny lists’ - do not allow your users to use a common, weak password. Screen passwords against a password ‘deny list’ of the most commonly used passwords, leaked passwords from website breaches and common words or phrases that relate to the service. Update this list at least yearly. Explain to users that this is what you are doing, and that this is why a password has been rejected.

Other than the three requirements listed above, do not set restrictions on how users should create a password. Research (see ‘Other resources’ below) indicates that doing so will cause people to reuse passwords across accounts, to create weak passwords with obvious substitutions or to forget their passwords. All this places unnecessary stress on your reset process and weakens the overall security of your service.

Properly set up and configured password strength meters can be a good way to easily communicate the requirements listed above to your users, and research has shown that good meters can assist users in choosing strong passwords. If you decide to use one, make sure it properly reflects what constitutes a strong or weak password.

Finally, remind your users that they should not reuse passwords from other services. In most circumstances you should not know what your user’s passwords are. However, some companies actively track compromised credentials that are traded on the dark web and will check these credentials against the hashes they hold on their systems to see if there is a match.

If you decide that this is something you want to do you need to carefully consider the potential legal implications of obtaining such lists, and you will need to explain very clearly how you use that data to your users (especially where the use of such data has led to a password reset or an account lockout).

If users receive an email asking them to reset their password without a proper explanation they will generally assume that the problem is with your service, so it is in your interests to explain precisely why you are taking this action.

What should we do about password expirations and resets?

You should only set password expirations if they are absolutely necessary for your particular circumstances. Regular expiry often causes people to change a single strong password for a series of weak passwords.

As a general rule, get your users to create a strong initial password and only change them if there are pressing reasons, such as a breach of your systems that may have resulted in the password hashes being compromised, or if you receive some other indication that a user’s password may have been compromised.

When deploying a password reset process you should ensure that it is secure. Do not send passwords over email, even if they are temporary – use one time links, and ensure that you do not leak the credentials in any referral headers.

You should also not be in a position where a member of your staff is able to ‘read out’ a user’s password to them, eg over the phone in a service call—this indicates that you are storing passwords in plaintext, which is, as described above, not appropriate. If you require a password to validate a user over the phone, set a separate phone password for the account.

You should also time limit any password reset credentials. The majority of users will probably reset their password immediately, but set a limit that fits your observed user behaviour.

What defences can we put in place against attacks?

Ensure that you are rate limiting or ‘throttling’ the number and frequency of incorrect login attempts. The precise number of attempts and the consequence of exceeding these limits will be for you to decide based on the specific circumstances of your organisation, but limiting to a certain number per hour, day and month is a good idea.

This will help to deter both bulk attackers and people targeting individual accounts.

There are additional considerations when implementing your rate limits:

• you should be aware that some attackers will deliberately work within your limits to avoid detection, and will still achieve a reasonable success rate, especially with targeted guessing;
• set your limits based on observed behaviour of both attackers and your users;
• be aware that overly-aggressive rate limiting can be used as a denial of service attack (remember that the UK GDPR requires the availability of personal data); and
• remember that a number of successful or unsuccessful access attempts to a range of different user accounts from the same device or IP address might be indicative of a bulk attack.

You should also consider whether other methods of preventing attacks might be appropriate. Examples of these methods could include, but are not limited to:

• the use of ‘CAPTCHAs’;
• creating an ‘allow list’ of IP addresses; and
• time limits or time delays after failed authentications.

What else do we need to consider?

You need to address how your system will respond to an attacker who has legitimate credentials for a user, or for multiple users. There is a distinct possibility that you will encounter this scenario given that both password reuse and website breaches are relatively common occurrences.

Techniques for recognising common user behaviour are becoming more advanced, and you could use these to develop a risk-based approach to verifying an authentication attempt. For example, if a user logs in from a new device or IP address you might consider requesting a second authentication factor and informing the user by another contact method of the login attempt.

It is however important to remember that collecting additional data from users in order to defend against authentication attacks could itself constitute processing personal data and should operate in compliance with the UK GDPR. This does not mean you cannot process this data, but you must ensure that you have considered the data protection implications of doing so.

You should consider providing your users with the facility to review a list of unsuccessful login attempts. This will allow people who might be specifically targeted to check for potential attacks manually. However, this will only be useful if you pay attention to reports from individuals that their accounts are being attacked.

You should implement two-factor or multifactor authentication wherever it is possible to do so - to take the most common example, a password and a one-time token generator. This will be more important where the personal data that can be accessed is of a sensitive nature, or could cause significant harm if it were compromised.

Other examples of a second factor that could be used include biometrics (fingerprints being the most common and easy to implement), smart cards or U2F keys and devices.

You will however need to ensure that any processing of biometric data for the purposes of uniquely identifying an individual is done in accordance with the requirements for processing special category data in both the UK GDPR and the Data Protection Act 2018.