At a glance

  • Although the 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 required under the GDPR?

The 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 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’.

What are the other considerations?

Although the 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.

This means that you cannot simply set up a password system and then forget about it – there must be a periodic review process.

You must also ensure that you are aware of the state of technological development in this area and must ensure that your processes and technologies are robust against evolving threats. For example, advances in processing power can reduce the effectiveness of cryptography, particular design choices can become outdated, and so on.

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

Article 25 of the 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.

In more detail – ICO guidance

Read our sections on security and data protection by design in the Guide to the GDPR.

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 have generally seen 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.

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 meant that some have become overwhelmed with access credentials and defaulted 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’.

Example

In 2012, the social networking site LinkedIn was hacked. It was thought at the time that passwords for around 6.5 million user accounts were stolen by cybercriminals. However, in May 2016, following the advertisement for sale on the dark web of 165 million user accounts and passwords, LinkedIn confirmed that the 2012 attack had actually resulted in the theft of email addresses and hashed passwords of approximately 165 million users.

The vast majority of the passwords were subsequently cracked and posted online less than a day after the further distribution, largely due to the use of SHA1 without a salt as the hashing algorithm. Due to the reuse of passwords across online services, a number of subsequent account takeovers at other services were attributed to the LinkedIn hack.

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 designing and implementing 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 must also consider what will happen if the SSO is compromised, as this will most likely also result in your user’s accounts 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.

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.

Further reading

Guidance on passwords from the NCSC:

Guidance on passwords from GetSafeOnline:

What should I consider when implementing a password system?

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. 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 National Institute of Standards in Technology (NIST) and the European Union Agency for Network and Information Security (ENISA). You should also be aware of any sector-specific guidelines that are available and may be applicable to you, eg from the European Payments Council.

You may also need to 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.

Example

In 2018, Twitter and GitHub discovered that errors in their logging systems had led to plaintext passwords for users being stored in log files. Although the log files were not exposed to anyone outside of the organisations, both Twitter and GitHub recommended or required that users changed their passwords. 

Further reading

Information on the status of a number of hashing functions can be found in NIST Special Publication 800-131A Revision 1 – Transitions: Recommendations for transitioning the use of cryptographic algorithms and key lengths (2015)

ENISA’s 2014 ‘Algorithms, key size and parameters’ report provides further information on the status of cryptographic hash functions. You should note that although SHA1 is listed as acceptable for legacy use, this was only until the SHA3 hashing function was finalised, which took place in 2015. SHA1 is now regarded as unsuitable for use.

The European Payments Council’s guidance on the use of cryptographic algorithms provides additional information if your organisation is part of this sector.

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 many browsers now mark pages that require secure input (such as login pages) as insecure if they are delivered over HTTP.

Further reading – ICO guidance

Read our guidance on encryption for more information about secure data transfer and HTTPS.

 

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 a 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 for more details on rate limiting).

Further reading

Read the NCSC’s ‘Let them paste passwords’ blog post for more information on why you should allow your users to paste passwords into password fields.

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;
  • 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 blacklisting—do not allow your users to use a common, weak password. Screen passwords against a ‘password blacklist’ of the most commonly used passwords, leaked passwords from website breaches and common words or phrases that relate to the service. Update this list on a yearly basis. Explain to users that this is what you are doing, and that this is why a password has been rejected.

Example

A password blacklist could be a feature of the software you use. Other lists are available online, e.g. SecLists and haveibeenpwned's password list.

It is also possible to find easy implementations, such as NIST Bad Passwords, which uses SecLists.

Other than the three requirements listed above, do not set restrictions on how users should create a password. Current research (see ‘Further reading’ 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.

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.

Further reading

Microsoft’s password guidance contains advice on passwords in the context of several Microsoft platforms. It includes guidance for IT administrators as well as users, and details a number of common password attacks and highlights a number of issues including the risks of placing restrictions on how users create passwords.

Advice from the Federal Trade Commission (FTC)  also discusses these issues. 

For more information on password strength meters, read this analysis from Sophos as well as the significant amount of research from Carnegie Mellon University.

 

Finally, remind your users that they should not reuse passwords from other sites. In most circumstances you should not have any idea what your user’s passwords are. However, some companies will 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).

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 personal data breach.

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.

Example

NIST guidance recommends that accounts with internet access should be limited to 100 consecutive failed attempts on a single account within a 30 day period, unless otherwise specified in the system being deployed.

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; 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 also 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’;
  • whitelisting IP addresses; and
  • time limits or time delays after failed authentications.

What else do we need to consider?

You will 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 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 also consider implementing 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 GDPR’s requirements for special category data, and/or an appropriate processing condition in Schedule 1 of the Data Protection Act 2018.

In more detail – ICO guidance

Read Protecting personal data in online services: learning from the mistakes of others (PDF) for more information.

For more information on special category data, read the section on key definitions in the Guide to the GDPR.

 

Further reading

Additional guidance on digital identities, hashing functions and algorithms and passwords in general includes: