Despite safeguards and, hopefully, an increasing awareness of cyber security, data leaks from websites happen and will happen all the time. Examples include, for example, the April data leak of 533 million Facebook users, including the data of more than 2.5 million Poles, and quite a few other leaks that security services regularly inform us about.
From the point of view of users, it is worth keeping up to date with reports on this subject and verifying that our data has not been exposed in such incidents. However, effective verification in this regard can only be done by a small proportion of users. In particular, non-technical people are likely to be rarely aware of the need to perform such verification at all. For this reason, it is worthwhile to cushion our system users and use the available leakage information to enhance the security of accounts in our systems. This type of approach is recommended by organizations such as NIST and OWASP.
One of NIST's recommendations, more specifically document SP 800-63B, recommends checking user passwords against leaked databases. Similar guidelines are also provided by OWASP ASVS, the standard for securing and testing web applications. In the current version 4.0.2, these guidelines can be found in the V2.1 Password Security Requirements section under 2.1.7. Below are excerpts from the documents, NIST, OWASP ASVS, respectively.
Both recommendations boil down to checking that passwords used by users have not already been leaked in various security incidents. Unfortunately, it is still a common practice for users to use the same passwords in several different systems. In such a situation, even if the password is properly complex and meets our password policy, it can be assumed that it is "burned" and known to potential attackers, and thus cannot perform its role.
How to check what passwords have been leaked and where to get a list of them?
To verify passwords for their presence in leaked data, you can use the Have I Been Pwned service, in particular the list of more than 300 million passwords provided by this service. I have already written about this service in an article titled Strong passwords and password usability - how passwords are cracked and what passwords are secure?
Passwords are made available in the form of SHA1 hashes, among other things, so that the file is not a list of passwords for dictionary attacks. Shorter lists of the most commonly used passwords, which are prepared precisely on the basis of passwords from known leaks, are also sometimes used for verification. The use of lists containing 1,000 or 10,000 of the most frequently used passwords is in line with the exact recommendation of OWASP ASVS. It makes sense to select only passwords that comply with the password policy for this list. Weaker passwords could not be used in our system anyway. Password lists can be found here, for example. It is also a good idea to add system-specific words to the list, for example, system name, user login, user name, or combinations of these.
For obvious reasons, it will be safer to compare passwords with as large a list as possible. There are also issues of usability and user reaction, for example, if the system disallows several different password suggestions. With a good implementation, even a full list of 300 million passwords should not significantly degrade the performance of the system, but it is nevertheless more challenging than with a dozen thousand passwords. An efficient implementation may simply be more time-consuming for developers.
It is a good idea to perform the check when creating an account at the registration stage, changing passwords, and possibly at the first login from implementing security or updating the list of leaked passwords.
How to inform the user about the reason for password rejection?
According to the NIST recommendation, at the time of rejection of a "burnt" password, it is worthwhile for the application to inform about the reason, i.e. the presence of such a password in the list of simple passwords, or passwords that have leaked from other systems. For the sake of non-technical users, it is worth informing about this fact in an accessible way, such as adding a reference to a more detailed explanation of what leaked password lists are. An example is the screenshot of password verification performed by Google, which is included later in the article.
Password verification from the users' point of view
Returning to the issue of users verifying passwords on their own, here the Have I Been Pwned service is also useful. The service allows us to search by our email address and phone number. The service also allows us to set up a notification, in case our email address appears in the data from subsequent leaks. If we receive a notification and check that there are passwords in the scope of the leaked data, we will know that the password needs to be changed immediately. Below is an example screen shot of the sample results of an account check on the service for an email address.
The result includes a brief information about the incident along with a list of the data that was disclosed, in my example these are E-mail addresses, Geographic locations, IP addresses, Names, Passwords. The Have I Been Pwned service is well-known in the security community and considered trusted, but it is worth remembering to approach all services advertising themselves as allowing you to check the security of your passwords with caution and not to enter your passwords in them, an example of this attack.
An example of the use of a password verification mechanism for leaking passwords is the Chrome browser, which allows you to check the security of your saved passwords. Chrome also checks whether passwords are strong (complex) enough. Such verification can be done, for example, by checking the security level of your Google account or directly in the browser by selecting the option to check passwords in the settings.
The security issue of saving passwords in the browser is already a topic for another article ☺. In general, I do not recommend saving passwords for important systems such as social networking accounts in the browser, but for less important systems, where there is no possibility of modifying important data or suspecting sensitive data, it can prove to be a convenient solution.
The screenshot below shows an example of the result of such a check for several weak passwords saved.
Summary
Finally, let's summarize some of the most important rules for password security, both from the point of view of the user and the application owner.
The most important password security rules for the user:
- We do not use the same passwords (or passwords that are very similar) for different applications.
- We regularly check whether our passwords have leaked (e.g., using notifications on Have I Been Pwned).
- We enable multi-component logins, or so-called 2FA/MFA, in systems that offer this possibility.
- We use strong (complex) passwords, which we memorize or save in a password manager (e.g. KeePass).
The most important password security rules for the application owner:
- Introduce a password policy (requirements for password length and complexity) and functionality to check password strength.
- Enabling multi-component logins, i.e. the so-called 2FA/MFA.
- Verifying that passwords are not on the list of weakest passwords and leaked passwords.
- Introducing protection against automated attacks in the form of adding several-second intervals between consecutive logins and blocking the account or slowing down logins if several consecutive failed login attempts are detected.
- Preventing the listing of application user logins.
