User authentication is the fundamental building block of computer security and the primary line of defense. It is the process of verifying an identity claimed by or for a system entity (RFC 2828). It consists of two distinct steps:
Face ID: is your face your identifier or your password? The answer is that your face is your identifier only if the system recognises you as a specific individual (identification). In most phone implementations, your face is a password used to verify that you are the authorised owner of the device — the identifier is the device itself.
The user ID serves three critical security purposes: (1) it determines whether the user is authorised to access the system, (2) it determines the user's privileges, and (3) it is used in discretionary access control (e.g., granting permission to other users to read files you own).
There are four general means of authenticating a user's identity, which can be used alone or in combination:
The four means are a classic exam question. Memorise the categories and be ready to give examples for each. The password recovery (security) questions fall under "something the individual knows" — and they must be as secure as the password itself.
Password authentication is the most widely used line of defense against intruders. The user provides a name/login (user ID) and a password; the system compares the password with the one stored for that login.
Despite its many security vulnerabilities, passwords remain the most commonly used user authentication technique for several reasons: client-side hardware (fingerprint scanners, smart card readers) requires software support on both client and server, creating a who-goes-first stalemate; physical tokens are expensive or inconvenient; single sign-on creates a single point of risk; and automated password managers have poor roaming/synchronisation support.
The textbook identifies the following principal attack strategies against passwords:
| Attack | Description | Countermeasure |
|---|---|---|
| Offline dictionary attack | Attacker obtains the password file, compares hashes against common passwords | Access control on password file, intrusion detection, rapid password reissuance |
| Specific account attack | Attacker targets a specific account with repeated password guesses | Account lockout after a limited number of failed attempts (typically 5) |
| Popular password attack | Attacker tries a popular password against many user IDs | Policies against common passwords; scan IP addresses and client cookies |
| Password guessing against single user | Attacker uses personal knowledge about the account holder | Training and enforcement of strong password policies |
| Workstation hijacking | Attacker uses an unattended logged-in workstation | Automatic logout after inactivity; intrusion detection |
| Exploiting user mistakes | Written passwords, social engineering, preconfigured passwords | User training, intrusion detection, multi-factor authentication |
| Exploiting multiple password use | Same password on different network devices | Policy forbidding same/similar passwords on different devices |
| Electronic monitoring | Eavesdropping on passwords communicated across a network | Encryption, challenge-response protocols |
Simple encryption of a password does NOT fix the eavesdropping problem — the encrypted password becomes the password itself and can be observed and replayed by an adversary. What is needed is a challenge-response protocol (discussed below).
A crucial distinction in password attacks is whether the attack is performed online or offline:
| Characteristic | Online Attack | Offline Attack |
|---|---|---|
| Interaction | Interacts with a live service or resource | No direct interaction with the target system |
| Data needed | Only the service endpoint | Intercepted or stolen data (e.g., password file) |
| Detection | Possible — rate limiting, lockout, logging | Very difficult — entirely under attacker's control |
| Speed | Limited by network latency and server rate limits | Only limited by hardware (CPU/GPU speed) |
| Example | SSH brute-force, web login guessing | Cracking a stolen /etc/shadow file with JtR |
Offline attacks are significantly more dangerous because once the attacker has the password file, they can dedicate unlimited computational resources to cracking it without any interaction with the target system. This is why protecting the password file is critical.
Storing passwords in cleartext is a very bad idea. A widely used security technique is to store hashed passwords with a salt value.
| Scheme | Hash | Salt | Output | Status |
|---|---|---|---|---|
Original crypt(3) | DES-based, 25 iterations | 12-bit | 11-char (56-bit key) | Inadequate, broken |
| MD5 crypt | MD5, 1000 iterations | Up to 48-bit | 128-bit | Replaced by SHA-512 |
| SHA-512 crypt | SHA-512 | 48+ bit | 512-bit | Current standard |
| Bcrypt (OpenBSD) | Blowfish-based | 128-bit | 192-bit | Most secure, configurable cost |
Know the three purposes of salt — this is a frequently asked question. Also understand why salt prevents detection of same-password users across systems: different salts mean different stored hashes even when the password is identical.
The attacker develops a large dictionary of likely passwords and tries each against the password file. Each candidate password must be hashed using each stored salt value and compared to the stored hashes. If no match is found, the cracker tries variations: backward spelling, added numbers/symbols, character substitutions, etc.
To trade space for time, the attacker pre-computes a mammoth table of hash values for all possible (password, salt) combinations. This can crack passwords very quickly once the table is built. The defence is a sufficiently large salt value and hash length — both FreeBSD (MD5/SHA-512) and OpenBSD (Bcrypt) approaches are secure from this attack for the foreseeable future.
Studies show that passwords provide fewer than 10 bits of security against online trawling attacks and only about 20 bits against optimal offline dictionary attacks. An attacker making 10 guesses per account (within rate limits) will compromise around 1% of accounts.
A key defence against password cracking is to deny the attacker access to the password file. Modern Unix-like systems use a shadow password file: the hashed passwords are stored in a separate file (e.g., /etc/shadow) accessible only by privileged users, while the user IDs remain in a world-readable file (/etc/passwd).
However, even with file protection, vulnerabilities remain:
A shadow password file alone is not sufficient. After a data breach, the attacker may obtain the file through OS exploits, backup media, or permission accidents. Password selection policies must complement access control.
Four basic techniques are used to eliminate guessable passwords while allowing users to select memorable ones:
| Strategy | How it works | Pros | Cons |
|---|---|---|---|
| User education | Teach users importance of strong passwords and provide guidelines | Low cost, easy to implement | Often ignored; users are poor judges of password strength |
| Computer-generated passwords | System assigns random passwords (e.g., FIPS 181 pronounceable syllables) | Very strong against guessing | Hard to remember; users write them down; poor acceptance |
| Reactive password checking | System periodically runs its own password cracker, cancels guessed passwords | Finds weak passwords in use | Resource intensive; existing passwords remain vulnerable until found |
| Proactive password checking | System checks password at selection time and rejects weak ones | Balances security and memorability; users choose their own | Must strike balance between acceptability and strength |
The best advice for choosing a password: use the first letter of each word of a phrase. Not a well-known phrase like "An apple a day keeps the doctor away" (Aaadktda), but something personal like "My dog's first name is Rex" (MdfniR) or "My sister Peg is 24 years old" (MsPi24yo).
Objects that a user possesses for user authentication are called tokens. The two most important categories are memory cards and smart cards.
Memory cards can store but do not process data. The most common example is the magnetic stripe bank card. They can be used alone for physical access (hotel rooms) but provide significantly greater security when combined with a password or PIN (ATMs).
Drawbacks: require a special reader, token can be lost, information is often stored in cleartext, and hotel locks must be properly reprogrammed at each room change.
Smart cards include an embedded microprocessor with processor, memory (ROM, EEPROM, RAM), and I/O ports. Some include cryptographic co-processors. They are categorised along four dimensions:
Be ready to explain the difference between memory cards and smart cards, the three authentication protocol types for smart tokens (static, dynamic password generator, challenge-response), and the difference between contact and contactless interfaces.
Biometric authentication authenticates an individual based on unique physical characteristics. It is based on pattern recognition — unlike passwords, biometric samples rarely match exactly.
Enrollment: The user presents a name and PIN/password; the system senses the biometric characteristic, digitises it, extracts features, and stores the resulting template associated with the user ID.
Verification (1:1 matching): The user enters a PIN and provides a biometric sample. The system extracts the feature and compares it to the stored template for that user. Match = authenticated.
Identification (1:N matching): The user provides only the biometric sample. The system compares against all stored templates. Match = identified.
Know the difference between verification (1:1, user claims an identity) and identification (1:N, system finds the identity). Be able to give examples of both static (fingerprint, retina, face) and dynamic (voice, handwriting, typing rhythm) biometrics.
Multi-factor authentication (MFA) refers to the use of more than one of the four authentication means. Systems using two factors are stronger than those using one; systems using three are stronger than those using two.
Example (two-step authentication):
NIST has deprecated out-of-band verification using SMS: "Out of band verification using SMS is deprecated, and will no longer be allowed in future releases of this guidance." SMS is not good for security because it is vulnerable to SIM-swapping attacks.
A critical consideration is whether the second factor uses an in-band or out-of-band channel. If a single device (e.g., a PC) is used to input both factors, and that device is compromised, both factors are compromised. Always carefully consider the threat model — the security of the channel used for the second step is paramount.
Passkeys represent the next step in user authentication, aiming to completely replace traditional usernames and passwords:
Passkeys are only partially supported and deployed. Even if standardised, there are relevant limitations in interoperability. As with any authentication mechanism, the threat model must be carefully considered.
Authentication based on biometrics can have different legal protection than passwords. The legal implications of passkeys (which combine biometrics with public-key cryptography) are still evolving.
John the Ripper (JtR) is the most famous open-source password cracking tool. It is used for both offensive testing and defensive verification of password quality. Its efficiency depends on the available hardware (CPU vs GPU) and the cracking mode selected.
JtR combines different cracking modes in the most appropriate order: single crack mode first (quick, uses info from the input file), then wordlist mode with common dictionaries, optionally with rules for variations, and finally incremental mode (exhaustive brute-force). Runtime details are logged in john.log.
JtR can also verify passwords used to protect PDF documents. A protected PDF contains a hashed version of the password. Use pdf2john.pl to extract the hash, then crack it with:
./pdf2john.pl document.pdf > hash.txt
./john --format=pdf hash.txtWhy do PDFs include a hashed version of the password? Without it, the only way to verify the password would be to attempt decryption — which is far more expensive. The hashed password enables quick verification but at the cost of enabling offline cracking attacks.
GPUs enable significant speedup for password cracking due to their massive parallelism and hardware implementation of encryption ciphers. While JtR has limited GPU support, dedicated tools like Hashcat are better suited for GPU-accelerated cracking.
An RA (Registration Authority) is a trusted entity that establishes and vouches for the identity of an applicant to a Credential Service Provider (CSP). In the NIST SP 800-63-3 model, the applicant applies to the RA to become a subscriber of a CSP. The RA performs identity proofing before the CSP issues credentials.
A CSP (Credential Service Provider) is an entity that issues electronic credentials to subscribers. After the RA verifies the applicant's identity, the CSP engages in an exchange with the subscriber to issue a credential — a data structure that authoritatively binds an identity and attributes to a token possessed by the subscriber.
User authentication is the process of verifying an identity claimed by or for a system entity (RFC 2828). It consists of two steps: identification (presenting an identifier) and verification (presenting authentication information that corroborates the binding between the entity and the identifier). It is the fundamental building block and primary line of defense for access control and user accountability.
Four means: something the individual knows (password, PIN, security answers), something the individual possesses (token, smartcard, key), something the individual is (static biometrics: fingerprint, retina, face), and something the individual does (dynamic biometrics: voice pattern, handwriting, typing rhythm).
Multi-factor authentication (MFA) refers to the use of more than one of the four authentication means. Implementations using two factors are stronger than those using only one. Example: password (something you know) + SMS code or dynamic PIN from a device (something you possess).
Assurance level describes an organisation's degree of certainty that a user has presented a credential referring to their identity. NIST SP 800-63-3 defines four levels (1 = little confidence to 4 = very high confidence). Potential impact (FIPS 199) defines the severity of an authentication error: Low (limited adverse effect), Moderate (significant adverse effect), or High (severe/catastrophic adverse effect). Higher impact systems require higher assurance levels.
The user provides a name/login (user ID) and a password. The system compares the password against the stored value for that user ID. The user ID determines whether the user is authorised, determines their privileges, and is used in discretionary access control. Modern systems store hashed (not plaintext) passwords with a salt value.
Offline dictionary attack, specific account attack, popular password attack, password guessing against single user, workstation hijacking, exploiting user mistakes (social engineering, written passwords, default passwords), exploiting multiple password use across devices, and electronic monitoring (eavesdropping on network traffic).
A salt is a random value combined with the password before hashing. Three purposes: (1) prevents duplicate passwords from being visible in the password file — different salts produce different hashes even for the same password; (2) greatly increases the difficulty of offline dictionary attacks — for a b-bit salt, the search space increases by a factor of 2b; (3) makes it nearly impossible to detect whether a user has the same password on different systems.
The salt is stored in cleartext in the password file alongside the hashed password. It is generated at the time the password is created or changed (using a pseudorandom or random number). The salt does not change over time — it remains constant for a given password. If the user changes their password, a new salt is generated.
Unix systems use hashed passwords with a salt. The original scheme (crypt(3)) used DES-based hashing with a 12-bit salt, 25 iterations, producing an 11-character hash. This is now considered inadequate. Modern schemes use MD5/SHA-512 with larger salts (48+ bits) and more iterations (1000+). OpenBSD uses Bcrypt (Blowfish-based) with 128-bit salt and a configurable cost factor.
A password dictionary is a collection of common words, phrases, and variations used in dictionary attacks. It may include words from online dictionaries, common passwords from data breaches, personal information patterns, and permutations (backward spelling, number substitutions, capitalisation variants). Tools like John the Ripper come with built-in wordlists.
OpenBSD is a widely used open-source Unix-like operating system known for its focus on security. It developed Bcrypt, a hash function based on the Blowfish symmetric block cipher that is considered the most secure Unix hash/salt scheme. Bcrypt uses a 128-bit salt, produces a 192-bit hash, and includes a configurable cost variable that increases computation time.
John the Ripper (JtR) is the most famous open-source password cracking tool, first developed in 1996. It supports multiple cracking modes: single crack (using information from input file), wordlist/dictionary mode, rules-based mode (applying variations to dictionary words), and incremental (brute-force) mode. It is used for both offensive testing and defensive password quality verification.
Even with encryption: (1) software vulnerabilities in the OS may allow bypassing access controls; (2) accidents of protection may render the file readable; (3) users who reuse passwords on other machines create cross-system vulnerabilities; (4) weak physical security may expose backup media; (5) network sniffing can capture passwords in transit.
Four strategies: (1) user education — teaching users to choose strong passwords; (2) computer-generated passwords — system assigns random (possibly pronounceable) passwords; (3) reactive password checking — system periodically runs a password cracker to find weak passwords; (4) proactive password checking (complex password policy) — system checks passwords at selection time and rejects weak ones.
If highly random, users cannot remember them and tend to write them down, creating a security risk. Even pronounceable generated passwords are hard to remember. Computer-generated password schemes historically have poor user acceptance. FIPS 181 defines a well-designed generator that creates pronounceable syllables, but user acceptance remains a challenge.
NIST SP 800-63-2 offers two equivalent options: basic16 (16+ characters) and comprehensive8 (8+ characters with uppercase, lowercase, digit, symbol, no dictionary words). Research by [KELL12] found basic16 is superior against large numbers of guesses. [KOMA11] found it is also easier for users. Longer passwords resist both brute-force and dictionary attacks more effectively while being easier for users to create (e.g., passphrases).
A proactive password checker should: reject passwords that are too short or too weak; check against dictionaries of common/forbidden passwords; enforce rules (e.g., must include different character types); optionally use neural-network evaluation or check against public data breaches (e.g., Have I Been Pwned API). The goal is to eliminate guessable passwords while allowing users to select memorable ones.
Token-based authentication uses objects that a user possesses (tokens) for authentication. Types include memory cards (store but don't process data, e.g., magnetic stripe cards) and smart cards (include an embedded microprocessor with processing capability). Tokens are often combined with a password or PIN for stronger security (two-factor authentication).
A memory card stores data but does not process it. The most common example is a magnetic stripe bank card. Using it alone is not secure because the data is often stored in cleartext and can be read/copied. It is usually combined with a PIN (e.g., ATM: card + PIN). Drawbacks: requires a special reader, token loss, information stored in cleartext.
A smart card contains an embedded microprocessor with processor, memory (ROM, EEPROM, RAM), and I/O ports, allowing it to process data and execute cryptographic operations. The key difference from a memory card is that smart cards can process data, not just store it. This enables more secure authentication protocols (dynamic password generation, challenge-response). Some smart cards include cryptographic co-processors.
Contact smart cards must be inserted into a reader with direct physical connection to gold-plated contacts on the card surface. Contactless cards communicate via radio frequencies using an embedded antenna, requiring only close proximity (~0.5 to 3 inches). Contactless cards derive power from the electromagnetic signal, making them ideal for applications requiring very fast interaction (building entry, payments).
Static: the token authenticates the user to the computer, similar to a memory token. Dynamic password generator: the token periodically generates a unique password (e.g., every minute); both token and system must be synchronised. Challenge-response: the computer sends a challenge (e.g., random string), and the token generates a response (e.g., encrypts the challenge with a private key); no synchronisation needed.
Remote user authentication is authentication over a network, the Internet, or a communications link. It is more complex than local authentication due to additional threats: eavesdropping, capturing passwords, and replaying observed authentication sequences. It generally relies on challenge-response protocols to counter these threats.
The user transmits their identity to the host. The host generates a random number (nonce) and returns it with function identifiers. The user responds with f(r', h(P')) — the hash of their password combined with the nonce. The host compares this to its stored f(r, h(P(U))). Advantages: (1) host stores only the hash, not the password; (2) the password hash is never transmitted directly; (3) the random nonce prevents replay attacks.
Client attacks (guessing, exhaustive search, false match for biometrics), host attacks (plaintext theft, dictionary search, template theft), eavesdropping/theft/copying (shoulder surfing, token theft, biometric spoofing), replay attacks (reusing captured authentication data), Trojan horse attacks (rogue client/capture device), and denial-of-service (lockout via multiple failed attempts).
Client attacks are attempts by an adversary to masquerade as a legitimate user without accessing the remote host or communications path — e.g., password guessing, exhaustive search, false biometric match. Countermeasures include large entropy, limited attempts. Host attacks target the user file at the host where passwords, passcodes, or templates are stored — e.g., plaintext theft, dictionary search, template theft. Countermeasures include hashing, access control, one-time passcodes.
In the context of passwords, eavesdropping refers to learning the password by observing the user (shoulder surfing), finding a written copy, or keystroke logging (keylogging) — installing malicious hardware/software to capture keystrokes. For tokens, the analogous threat is theft or physical copying. For biometrics, it is copying or imitating the biometric parameter. Multi-factor authentication is resistant to many eavesdropping attacks.
A replay attack involves an adversary repeating a previously captured user authentication response (e.g., re-sending a captured encrypted password). The most common countermeasure is the challenge-response protocol, where the host generates a unique random number (nonce) for each authentication session. Because the response depends on this nonce, a previously captured response is invalid for a new session.
In a Trojan horse attack, a malicious application or physical device masquerades as an authentic one to capture a user's password, passcode, or biometric. Example: a rogue ATM or a fake login page that records the user's credentials. The adversary then uses the captured information to masquerade as the legitimate user. Countermeasures include authenticating the client or capture device within a trusted security perimeter.
Computer-generated passwords are strong against guessing but users have trouble remembering them, leading them to write passwords down. Poor user acceptance. Reactive password checking: the system periodically runs its own cracker and cancels guessed passwords. Resource-intensive, and existing passwords remain vulnerable until discovered. Proactive password checking: the system checks password strength at selection time and rejects weak passwords. Best balance of security and usability — eliminates guessable passwords while allowing users to choose memorable ones, provided the checker is well-designed.
Single-password authentication is the simplest form: user provides a user ID and password. The user ID identifies the user; the password verifies the claim. It is widely used but has many vulnerabilities: susceptible to guessing, eavesdropping, phishing, dictionary attacks, and social engineering. It provides only one factor (something you know). While convenient and inexpensive, it is increasingly inadequate as a sole mechanism, which is why modern systems are moving toward multi-factor authentication and passkeys.
Users exist for accountability and access control: each user has specific privileges. The super-user (root/administrator) has unrestricted access for system administration. In Discretionary Access Control (DAC), users control access to their own resources. Problems include: the set-user-ID (SUID) mechanism can lead to privilege escalation if a vulnerable program runs with super-user privileges; users may inadvertently grant excessive permissions; and shared group IDs can lead to unintended access. Careful management of SUID/SGID bits is essential.
Something the individual knows (password, PIN), something the individual possesses (token, smartcard), something the individual is (static biometrics: fingerprint, retina, face), and something the individual does (dynamic biometrics: voice pattern, handwriting, typing rhythm).
(1) Prevents duplicate passwords from being visible — different salts produce different hashes for the same password. (2) Greatly increases offline dictionary attack difficulty — a b-bit salt multiplies the search space by 2b. (3) Makes it nearly impossible to determine if a user has the same password on different systems.
Verification (1:1 matching): the user claims an identity (e.g., enters a PIN) and provides a biometric sample; the system compares against the single stored template for that identity. Identification (1:N matching): the user provides only a biometric sample; the system searches all stored templates to find a match.
A memory card stores data but does not process it (e.g., magnetic stripe card). A smart card contains an embedded microprocessor that can process data, execute cryptographic operations, and support advanced authentication protocols (dynamic password generation, challenge-response).
Online attacks interact with a live service — they are detectable and limited by network latency and rate limiting. Offline attacks use stolen/intercepted data (e.g., the password file) with no interaction with the target system — they are undetectable and limited only by the attacker's hardware. Offline attacks are far more dangerous.
SMS is vulnerable to SIM-swapping attacks, where an attacker convinces the mobile carrier to transfer the victim's phone number to a SIM card controlled by the attacker. This allows interception of SMS verification codes. NIST recommends using authenticator apps or hardware tokens instead of SMS for out-of-band verification.