It will not have escaped most people’s attention: on 12 February, a major cyberattack took place at telecom provider Odido, in which personal data of approximately 6.5 million people was lost (according to NOS research).
As unfortunate as it is, data breaches are increasingly becoming a daily occurrence. It is therefore important to consider the possible implications of such breaches and the risks they create. Much has already been written about possible fake messages (phishing) that affected individuals should be alert to. In addition, attention must be paid to the safety of certain individuals, now that protected addresses have also been published.
One topic that has received little attention is the risk to verification techniques. Many organizations use “verification questions” to determine whether they are dealing with the correct person. Examples include: “What is your date of birth?” or “What is your BSN (citizen service number)?” Leaving aside whether the BSN is suitable for this purpose (there are strict rules regarding its use), organizations should remain alert as to whether their verification technique may have been compromised.
In this blog, I will discuss the risks that such data breaches pose to verification processes, the role of the General Data Protection Regulation (GDPR), and alternative verification methods your organization can use to better protect itself against potential breaches.
Note: this blog focuses on verification methods that take place outside digital customer environments.
Defining the concept of verification
To properly understand where the risks lie in verification processes, it is important to be aware of the distinction between several terms that are often used interchangeably in practice. This blog focuses on the following concepts:
-
Identification: the claim of identity (“Hello, I am user X”).
-
Authentication (proving): proving identity using means such as a password, 2FA code, or fingerprint.
-
Verification (checking): the process in which the system checks whether the provided evidence matches stored data, often to ensure that the user is who they claim to be.
-
Authorization (permission): determines which data or functionalities the verified user is allowed to access.
Risks
In some data breaches, information eventually becomes publicly available. Data is highly valuable to hackers, because it may allow them to gain access to systems to which they are not entitled.
This can happen, for example, as follows: a hacker who has obtained someone’s name, address, city of residence, or BSN pretends to be that person via telephone or a chat service. Employees of the organization the hacker is trying to access may then ask for verification information such as date of birth, address, city of residence, and/or the last four digits of a person’s BSN.
When the hacker can simply read these details back, it becomes difficult for the employee to distinguish between the hacker and the actual individual concerned.
Such a verification system is known as Knowledge-Based Authentication (KBA). While KBA may once have been a convenient system, this verification method now poses a significant risk in the age of the internet. Verification methods should not rely on publicly available information. This also applies to non-public data that suddenly becomes widely available after a major incident, such as a data breach.
If your organization still uses KBA, it is advisable to adopt a better alternative.
GDPR – Legal framework
It is important to consider the obligations under the GDPR regarding the security of personal data. Under Article 5(1)(f) GDPR, personal data must be processed in a way that ensures appropriate security. This must be achieved by implementing appropriate technical or organizational measures (Article 32 GDPR).
Aside from the fact that a data breach can have serious consequences for affected individuals, it can also lead to fines if the required security measures are not in place. This underscores the importance of ensuring that your organization uses appropriate verification methods.
Alternative: Multi-Factor Authentication (MFA)
The fact that a large amount of information is publicly available, partly due to frequent incidents, means organizations must carefully reconsider how they handle verification. In an era of large-scale data breaches, knowledge is no longer truly secret. We therefore recommend that organizations always work with multi-factor authentication (MFA).
MFA means that a user identifies themselves using at least two different factors. The factors used as proof can be divided into three categories:
-
Something you know (knowledge factor)
-
Something you have (possession factor)
-
Something you are (inherence factor)
Below is a detailed explanation of these categories.
Knowledge factor
When someone must provide information during the verification process to prove their identity based on something only they should know, this is referred to as a knowledge factor. Examples include a password or BSN.
Within this dimension, organizations often use verification questions, which can be divided into two types: static and dynamic.
Static verification questions are based on fixed information that does not change, such as date or place of birth, passwords, or passport numbers. The problem with this method is that such information may already be publicly known or may become public through data breaches.
Dynamic verification questions, by contrast, are context- or time-based questions that are not fixed. An example would be asking for the payment reference of a recent transaction. Dynamic verification questions are particularly useful when individuals want to access information by phone but do not have access to a digital environment or app.
Possession factor
If the verification process involves proving identity using something a person possesses, it is known as a possession factor. Examples include a SIM card or a phone, which can receive an SMS or a notification via an authenticator app that generates a one-time password.
Inherence factor
An inherence factor is used when someone proves their identity using unique biological characteristics, such as a fingerprint or iris scan.
In the Netherlands, the use of such data for security purposes is subject to strict conditions. It is only permitted when the situation requires such a high level of security that no alternative method is suitable. An example would be access control for a nuclear power plant.
Your verification technique within the PDCA cycle
Good policy is constantly subject to the Plan–Do–Check–Act (PDCA) cycle, meaning it is regularly reviewed. The same applies to verification techniques. Make sure to review them, especially if they depend on data that may be publicly available or may have become public due to an incident.
Consider the following when establishing or reviewing your verification technique:
-
Design verification as if personal data is public. Always assume that data such as name, address, and date of birth may already be known to an attacker. Do not rely solely on personal data when verifying identities and always use multiple layers of verification.
-
Be aware that weak verification can lead to incidents or data breaches. If it later appears that the verification method used was not appropriate given the risks involved, this can create risks for individuals, your organization, and potential enforcement or liability under the GDPR.
-
Periodically evaluate your verification process. Regularly reviewing your verification procedures reduces the risk of data breaches and helps ensure compliance with GDPR requirements.
-
Apply risk-based verification. The greater the potential consequences and the more sensitive the data, the stronger the verification method should be.
Do you still have questions after reading this blog? Feel free to contact us!
