Authentication¶

Narrowly defined, authentication confirms the identity of a user logging in and binds the corresponding user identity to a subject. In the following, the concept is defined more generally so that it also applies to the authentication of devices and applications, but after that the focus is specifically on user authentication, starting with identity management.

Authentication can be based on inherent characteristics, behaviour, knowledge, or possession. These are listed above from the most permanent to the most changeable. “Behaviour” refers to actions or conduct, and in the following list it is embedded in two other categories (1 and 3).

In order for an entity to be authenticated—that is, reliably identified (or recognised as the same as when encountered previously)—it must have some verifiable property that others do not have:

It is something. This applies, of course, only to humans. The distinguishing property is physical, such as a fingerprint, hand geometry, voice, retina or iris, facial thermal pattern, or skull shape. Measuring such characteristics is called biometrics. The property may also be based on behavioural traits, such as handwriting, typing patterns, or speech. (Devices also have their “inherent characteristics”, but even specially designed PUF devices are typically not used directly for inherent authentication but for generating device-specific secrets.)
It has something in its possession, such as a key, a smart card, or another kind of token. What is possessed must, of course, be something that cannot easily be copied or forged. The possessing entity may also be something other than a human. Examples of tokens include electronic ID cards and a mobile phone’s SIM. Devices may possess, for example, a TPM chip.
It knows something, typically a password and more generally a shared secret. Preferably, such information should be of the kind that does not need to be revealed, yet still allows others to be convinced that the entity knows it. This type of knowledge corresponds to the ability to do something unique, something that cannot be imitated. Signing with a private key is a typical example. In that case, the secret is not shared but asymmetric. Naturally, the knowledge may also be held by a device, in which case it is primarily the device that is identified rather than its user (e.g. a SIM in a phone, to which the human first authenticates using a PIN). Knowledge that is not disclosed is verified using a challenge–response procedure, which is discussed later specifically in a device-based context.

All three of these methods are examined later in this section, and behaviour-based authentication is also treated separately. A fifth possibility has also been studied: the social network. According to this, “you are someone specific because you know certain other people”. It has long been used in many everyday contexts, but it is not typically suitable for authentication requiring strict logical precision.

The design of authentication protocols is a mature area of information security research, and it is well supported by formal analysis tools. Standard protocols such as Kerberos, SAML, and OAuth are widely used.

Identity management¶

Identity management systems are responsible for the creation, use, and removal of digital identities. When creating an identity, it is necessary to consider how strongly the digital identity should be linked to a person. In some cases, strong links must be established and documented. For example, anti-money laundering regulations may require thorough verification of an account holder’s identity. In other cases, a digital identity need not be linked to a person. For instance, privacy by design implies that such systems should use digital identities that cannot be linked to individuals. Identity management may also link access rights to a digital identity, either directly or via an intermediate layer such as a role. Digital identities should be removable when they are no longer needed, for example when a person leaves an organisation. It must then be ensured that this is done across all systems in which the person’s digital identity has been registered.

Identity management

Procedures for managing user and device identifiers, roles, and groups.

Digital identities exist at different levels. For internal system purposes, there are identities such as operating system user accounts. These identities must be locally unique, and administrators can create them (in Linux). This can lead to problems when an identity is deactivated and later assigned to someone else. The new user may inadvertently gain access to resources previously accessible to the previous holder of that identity. When organisations merge, identity conflicts may arise, which identity management must resolve. Alternatively, identities can be long random strings (in Windows). The probability of the aforementioned problems occurring is then negligible, but when a user account is recreated, a new random identity is also created, and access rights must be reassigned.

Digital identities such as usernames and email addresses may be random strings, but it is often preferable to define meaningful identities. It is convenient to communicate using an address whose meaning is understandable. An email address may be deactivated and later assigned to a new user with the same name, but in that case the new user may receive emails intended for the previous owner.

Web applications often use email addresses as digital identities. This is convenient for reaching users and also for users themselves, as they do not need to remember a new identity. Alternatives exist, for example FIDO UAF, where digital identities are randomly generated public keys and password resets are unnecessary because passwords are not used.

Identity management can also be viewed from the perspective of the individual. A person who uses different identities in different organisations may wish to control how their identity is revealed to members of those organisations.

User authentication¶

A user has a relatively persistent identity that is associated with the relatively temporary subjects (i.e. processes) the user creates when logging into a system. The identity associated with subjects is one of their security attributes. Others may include information about groups, roles, usage restrictions, and events occurring during their lifecycle. User authentication confirms the security attributes of a subject by providing sufficient assurance that the user identity is correct. The strength of authentication—that is, the degree of assurance—should be proportional to the risk being mitigated.

The above definition is almost the same as saying that a user is who they claim to be. The difference is the emphasis that the subjects created by the user are the entities that carry the user’s “inherited” attributes when they make access requests and encounter access control. The user does not perform these actions directly, but user authentication supports accountability through the subjects.

There are access control systems in which the security attributes of a subject persist throughout its lifecycle. Many operating systems use this approach. Changes in the security policy do not affect running processes, but since their lifetime is limited, the new policy will eventually take effect. Alternatively, a subject’s attributes are verified each time it sends an access request. For example, a user who is already logged into a banking application may be re-authenticated when making a payment request. In this case, the perspective shifts from subjects to individual requests, and authentication ensures that the security attributes sent with the request to the decision-making algorithm are correct.

Passwords¶

When authentication is of the “something you know” type, passwords, passphrases, or patterns may be used. The same applies to all of these as is described here for passwords. Protective measures on the system side include storing hashed (Linux, Unix) or encrypted (Windows) passwords, salting passwords, and using a shadow password file, which moves sensitive data away from password files that are readable by all users. A salt is random data fed into the hash function together with the password, and the resulting hash is stored in the password file along with the salt. Using hashes prevents an attacker from learning passwords even if the password file is exposed. Salting the hash protects passwords against rainbow tables and other precomputation attacks.

	password	hash (SHA256)
Tiina	password123	0d438c00cff7142df79b898680de63d92c9b9eb6f7dc926a87c580f6691a3cc1
Jukka	password123	0d438c00cff7142df79b898680de63d92c9b9eb6f7dc926a87c580f6691a3cc1

Users in the table above have made questionable password choices. Not only are the passwords extremely weak, but the hashes computed from them are identical. If an attacker gains access to the hashes, they can immediately conclude that two users have the same password.

The table below illustrates how the situation improves somewhat when salts are added to the passwords. An attacker can no longer deduce from the hashes that two users share the same password. This still does not remove the fact that these users should immediately change their passwords to more secure ones.

	password	salt	hash (password + salt) (SHA256)
Tiina	salasana123	A43F567B3DFF7809	32afb2957edfb2b763b08a17bfed200b759314c1a374da57f93a673d973be91f
Jukka	salasana123	C341EF78CB20A512	69bc6396c0b04bccd28ad421f1fd3ca5c45f5e80b2967a016c50151565c32648

From the users’ perspective, password security includes guiding users to use appropriate passwords and to manage them properly. For example, information security awareness campaigns aim to instil behaviour that ensures a connection between a person and the user identity appearing in a system. Recommendations in this area are constantly evolving. The Digital Identity Guidelines published by NIST are based on assessments of the observed effectiveness of previous password policies and also take into account that users today must manage passwords for multiple accounts and services. The recommendations advise:

avoiding automatic password expiration; passwords should only be changed when there is a reason to do so;
avoiding complex password rules filled with special characters; password length is more important than complexity;
avoiding the use of password hints or knowledge-based authentication (e.g. security questions during password recovery), as too much personal information is now available, for example on social media;
avoiding the “show password while typing” option and avoiding allowing text to be pasted into password fields.

Password-based remote authentication protocols include RADIUS, DIAMETER, HTTP Digest Authentication, and to some extent Kerberos.

Biometrics for authentication¶

Passwords work poorly in practice because they place a burden on the user’s memory. This leads to insecure shortcuts, such as using the same password across multiple services, choosing passwords that are too short and easy, or adopting vague and impractical password management practices. Biometrics is an alternative that avoids the cognitive burden associated with password-based authentication. Fingerprint and facial recognition are the two main biometric authentication methods. Biometrics is an example of “something you are” authentication.

Biometric traits must be sufficiently distinctive to tell users apart, but fingerprints or facial features cannot be considered secrets. Biometric characteristics are therefore better treated as public information, for example in security analysis. During authentication, the system must allow for some variation in biometric traits: a finger may be sweaty or swollen due to temperature. This can be handled either by the capabilities of the authenticating device or system, or by involving a human to supervise the authentication process. It must also be verified that the subject being authenticated is alive and not, for example, a mould of a finger. Biometric authentication relies on the following assumptions:

Biometric traits uniquely identify a person, e.g. faces, fingerprints, and iris patterns.
The traits are stable. However, for example, the effect of ageing on fingerprint recognition is being studied.
The traits can be easily stored in the configuration of the authentication system.
The traits cannot be forged during user authentication.

Biometric authentication (often called verification in biometrics) begins with a template stored in the authentication device. A feature vector is derived from the template. The template could be, for example, an image of a fingerprint, and the features are the locations of fingerprint details (e.g. ridge endings, bifurcations, loops, etc.). Initially, users register a reference feature vector. During authentication, a new template is read from the fingerprint, features are extracted, and compared with the stored reference. The user is authenticated if the number of matching features exceeds a certain threshold.

The process may fail for several reasons:

Failure in reading features: this may occur during registration if a sufficient number of features cannot be read, or during authentication.
False rejections: a legitimate user is rejected because the number of matches between reference features and those read during authentication is insufficient.
False acceptances: an incorrect user is accepted because the threshold is exceeded for some reason.
Spoofing: the recognition system is deceived, for example with a moulded fingerprint. Liveness detection attempts to ensure that features are read from the actual person being authenticated.

Biometric identification based on facial recognition or fingerprints is increasingly used, for example at automated border control points. Biometric authentication, in contrast, is a feature of mobile devices. Identifying a user based on biometrics requires more biometric data than authentication, which can succeed with partial data. This difference leads to distinct security and privacy concerns. It is therefore important to understand that using biometrics for authentication and for identification are different matters, and system design should take this into account. If the distinction is unclear, read more, for example, here.

Authentication tokens¶

When authentication is based on a device issued to the user (i.e. a token or security key (≠ cryptographic key)), the device generates a one-time password (OTP), synchronised with the authenticator or produced as a response to a challenge issued by the authenticator. Possession of the device is therefore necessary for successful authentication, making this a “something you have” type.

A token may be a small handheld device with an LED display showing the one-time password. When logging into a service, the user enters the displayed password. Examples include RSA SecurID and YubiKey. In addition to a display, a token may include a numeric keypad. When the user receives a challenge from the service, for example an 8-digit number, they enter it into the token. The token calculates a response to be entered into the service. Some online banking systems use this type of authentication for account holders. The challenge can also be entered via a QR code if the token can scan one from a display provided by the service (a separate PhotoTAN device or a token application on a phone). When authentication is based on a shared secret between the token and the server, different tokens are required for different servers.

A FIDO authenticator is a token capable of generating public/private key pairs. Public keys act as identifiers and private keys are used to create digital signatures. In FIDO UAF, users register a public key with the server. The same token can be used with multiple servers, but with different keys. User authentication is based on a challenge–response method, where the user’s authenticator device digitally signs a response to a challenge issued by the server. The response is verified using the public key registered with the server.

In some applications, possession of the token is sufficient for user authentication. In others, authentication is a two-step process. First, the token authenticates the user, for example using a PIN or fingerprint. In the second step, the server authenticates the token. Depending on the threat model, this combination of a “weak” and a “strong” step may or may not provide sufficient security.

Smartphone applications can provide the same functions as authentication tokens, but smartphones are not dedicated security devices. User authentication may therefore be compromised through attacks on the smartphone. These risks may increase if the smartphone allows secondary authentication while partially locked. This is less burdensome for the user but also less secure. A tension arises where device manufacturers benefit from ease of use, while providers of sensitive services benefit from security comparable to dedicated tokens.

Behaviour-based authentication¶

Behaviour-based authentication analyses “what you do” and is suitable for continuous authentication. Examples include keystroke dynamics, handwriting, and voice recognition. Keystrokes can be measured without special devices. Special pens or writing pads can measure writing speed or pen pressure. Smartphones commonly include a microphone, touchscreen, and sensors related to motion and orientation, which are suitable for continuous authentication. Behaviour-based authentication is subject to the same requirements listed for biometrics:

Behavioural traits uniquely identify an individual.
The traits are stable and not affected by temporary disturbances.
The traits can be easily stored in the configuration of the authentication system.
The traits cannot be forged during user authentication.

Advocates of continuous authentication promise minimal user burden and maximal security. Users are not burdened because nothing beyond normal activity is required. However, variation in behaviour may lead to false rejections. For example, how does having a cold affect voice recognition? Security, in turn, depends on how well the system can determine that the authenticated subject is a real, living person, and not, for example, a speech synthesiser or a highly skilled imitator. Without a precise threat model, behaviour-based authentication can only provide uncertain security guarantees. There is extensive research on different methods. Criteria for evaluating the usefulness of such research include sample size and composition, the existence of longitudinal studies, the presence of a detailed threat model, and resistance to targeted impersonation. The following is a quotation from a different type of study (2025), based on interviews and surveys: “Our findings reveal a paradox: while the public increasingly relies on biometrics for convenience, experts express grave concerns about the spoofing of static modalities like face and voice recognition.”

Two-factor authentication (2FA)¶

Multi-factor authentication (MFA) combines multiple user authentication methods to improve security. The Revised Payment Services Directive (PSD2, 2015) requires two-factor authentication for online payments (with some exceptions) in regulating financial service providers. PSD2 is thus an example of large-scale adoption of 2FA solutions.

The two factors in 2FA may be a password and an authentication token. Transaction authentication numbers (TANs) are generated from these and are also uniquely linked to the content of the transaction. The token may be a separate device. If it is tied to only one payment service, the customer needs multiple devices. Devices used with multiple services require some degree of standardisation. The FIDO Alliance has created standards for PSD2-compliant two-factor authentication.

The token may also be a smartphone registered with the service. In this case, customers can install applications for multiple services on the same device. Many banks have favoured this approach. However, when the same device handles passwords (or PINs) and TAN codes, the two mechanisms are no longer independent, which reduces the claimed security benefits of 2FA.

eIDAS regulation

The European regulation on trust services and electronic identification (eID Regulation No 910/2014) defines requirements for devices used to create secure signatures. PSD2 does not impose security requirements on devices used for user authentication but aims to “allow the use of all general-purpose devices (such as computers, tablets, and mobile phones) for executing various payment services”. Thus, PSD2 and the eID regulation balance usability and security in different ways. Achieving this balance is a well-known and difficult compromise.

Authentication in distributed systems (advanced)¶

In distributed systems, access control is based not on users’ processes but on authenticated sessions, which in turn are based on cryptographic keys. These are called session keys, and their establishment is a core feature of user authentication. Kerberos below provides an example.

Kerberos (advanced)¶

Kerberos is an authentication service developed at MIT in the late 1980s, using a trusted third party and symmetric encryption. From the user’s perspective, the system implements single sign-on for network services. The most common operating systems have since adopted Kerberos or its variants for user authentication. For example, Active Directory—the Windows domain user database and directory service—uses Kerberos together with the LDAP directory protocol.

The goal is for a client to authenticate to a target server S. The trusted third party is the Kerberos Authentication Server (KAS), with which the client shares a password. From this, both the client and the KAS derive a symmetric encryption key K. In response to a client request, the KAS sends the client an encrypted session key and an encrypted ticket for service S. The client decrypts the session key encrypted with K using their password. Using the session key, the client encrypts its own identifier (and a timestamp) and sends the resulting authenticator along with the ticket to service S. Service S considers the client authentic because it can decrypt the ticket using the key shared between S and the KAS, and the ticket contains the same session key used to decrypt the authenticator, revealing the client’s details.

The Ticket Granting Server (TGS) introduces an additional layer between the client and the target server. The protocol is repeated almost identically twice: in the first phase, the TGS acts like S above, and in the final phase like the KAS. Separating roles aims at efficiency: the KAS (and its access database) is contacted once when the user logs into their machine. After that, the ticket issued by the KAS (the ticket-granting ticket, TGT) is used with the TGS once for each type of service, and the ticket received from it (the service-granting ticket) is then used with the target service as often as needed. The TGS may also apply access control when deciding whether to issue a ticket for use with server S.

Kerberos is named for having three roles. In addition to authentication, it can also be used to implement the two other main topics of this module: authorisation and accountability (see the explanation alongside an image of the real Kerberos). Other protocols serving these three purposes include RADIUS, Diameter, and TACACS+.

Kerberos also works in federated identity management. Similar ticket-based mechanisms can be found in the standards

SAML, Security Assertion Markup Language: security assertions are statements, for example, that someone has access to a resource. SAML also includes specifications for protocol messages.
OAuth, Open Authorisation. This is specifically about delegating access. Built on top of this is:
OpenID Connect, which focuses on authentication and also conveys identity information.

The linked pages are commercial, but appropriate.