The asset being protected here is the binding between a real person and a digital identity. Authentication is the gate that defends that binding; everything else is the chain vulnerability → threat → attack → CIA consequence → countermeasure applied to that one gate. We walk the four means of proving identity, then attack and defend each: passwords (storage, salting, cracking, selection), tokens, and biometrics — finishing with the network case (remote authentication, challenge-response) and the attack taxonomy that ties all three together.
The problem. Before a system can decide what you may do, it must be sure you are who you claim to be. Get this gate wrong and every access-control rule downstream is meaningless — which is why authentication is the fundamental building block and primary line of defense, and the basis for both access control and user accountability.
Precise definition. User authentication is the process of verifying an identity claimed by or for a system entity. In plain terms: convincing the system that the person at the keyboard really owns the identity they are presenting. It is built from two distinct steps, and keeping them separate is the point:
The user ID produced by identification then does triple duty: (1) it establishes that the user is authorized to access the system, (2) it fixes the user's privileges, and (3) it is consumed by access control downstream — the same ID that names you in discretionary permissions (cross-link: Cyber-Access-Control, where this ID drives DAC and the SUID/SGID mechanism).
Face ID: is your face the identifier or the password? Usually the password. The device is the identifier (the claim "I am this phone's owner"); your face is the verification information that corroborates it. The face only becomes an identifier when a system uses it to find who you are out of many — that 1:N case is biometric identification, covered later.
Punchline: identification says "I am Alice"; authentication is the work of believing it. Confuse the two and you have named a door without checking the lock.
The problem. Verification compares a presented secret against a stored one — but how did that binding get created in the first place, and how much should we trust it? That is the enrollment question that precedes every login.
Two roles set up the binding. A Registration Authority (RA) is a trusted entity that establishes and vouches for an applicant's real-world identity (identity proofing). A Credential Service Provider (CSP) then issues the electronic credential — the data structure that authoritatively binds the identity to the token the subscriber will later present. Sequence: applicant → RA (proofs identity) → CSP (issues credential) → subscriber.
How much the binding is worth is captured by two graded scales. Assurance level is the degree of confidence that the user who presented a credential really owns the claimed identity — four levels, from level 1 (little or no confidence) to level 4 (very high confidence). Potential impact is the severity of an authentication error — Low (limited adverse effect), Moderate (significant adverse effect), High (severe or catastrophic). The design rule that connects them: the higher the potential impact, the higher the required assurance level.
Punchline: a weak login on a high-impact system is a mismatch, not a convenience — assurance must rise to meet the stakes.
The problem. Any proof of identity must rest on something an impostor cannot supply. There are exactly four general means, used alone or combined; each is a different kind of secret with a different failure mode.
Security (password-recovery) questions live in the knows category and must be as secure as the password itself — a "knows" factor whose answer is on your public profile is not a second secret, it is a back door.
Punchline: the four means are the only levers you have; combining levers from different categories is exactly what multi-factor authentication (§14) means.
How it works. The user presents a name/login (the user ID) and a password; the system compares the password against the value stored for that login and, on a match, binds the session to the user's privileges. It is the most widely used line of defense against intruders.
Why it persists despite being weak. Client-side hardware (fingerprint or smartcard readers) needs software support on both ends — a who-goes-first stalemate; physical tokens are costly or inconvenient; single sign-on concentrates risk into one point of failure; and password managers historically had poor roaming/sync. So passwords survive by default, not by merit.
Punchline: the password is a single secret shared between human memory and a server file — both ends are the chapter's two big vulnerabilities (eavesdropping at the human end, theft at the server end), and the rest of this chapter is the fight over those two ends.
The asset under attack is the stored or transmitted password. The vulnerability: the same secret lives in two exposed places — a file on the server (which can be stolen and worked on offline) and the wire/human at the front (which can be observed or tricked). Stallings lists eight principal attack strategies — keep them countable, grouped by where they strike:
Against the stored file (offline-leaning):
123456 or Password1) against many user IDs at once, so no single account hits its lockout threshold. CIA consequence: Confidentiality first (one weak account's credentials are exposed), then Integrity (those credentials are used to masquerade). Not Availability: the attacker wants quiet access, not downtime.Against a live login (online):
Against the human and the environment:
The cross-cutting distinction: online vs offline. Both pursue the same shared problem (recover a usable password), but the difference decides everything about defense:
| Axis | Online attack | Offline attack |
|---|---|---|
| Interaction | Talks to a live service/resource | No interaction; uses intercepted or stolen data |
| Detectable? | Yes — logging, rate limits, lockout | Almost never — entirely under attacker control |
| Speed limit | Network latency + server rate limits | Only the attacker's hardware (CPU/GPU) |
| Example | SSH brute force; web login guessing | Cracking a stolen /etc/shadow |
When-to-use / consequence: rate-limits and lockout defeat online attacks but do nothing offline — once the file is stolen, only the cost of hashing protects you, which is why §6–§7 matter so much.
Account lockout after N failed attempts (typically 5) stops online guessing — but it is itself a denial-of-service lever: an attacker can deliberately lock out a victim. CIA: Availability. Useful but double-edged.
Simply encrypting the transmitted password does not stop eavesdropping: the ciphertext becomes the password and can be observed and replayed. The real fix is a challenge-response protocol (§12).
Punchline: every attack targets one of two endpoints — the server file (offline guessing, defeated only by strong hashing) or the human/wire at the front (eavesdropping, social engineering, defeated by limits and user discipline) — which is exactly why the defenses split into hashing strength (§6–§7) and rate-limiting/user education (§9).
The problem. Storing passwords in clear is a very bad idea: the sysadmin could read every password (and check whether you reuse it elsewhere), and an intruder who reaches the file gets an enormously valuable asset outright. So passwords are never stored in clear.
The mechanism. Store a hash of the password combined with a salt. The salt is a random value, generated per password, stored in clear next to the hash. It composes with a building block from Cyber-Cryptography: a one-way hash function, deliberately made slow to throttle the attacker's guess rate.
Loading a new password (purpose: produce a stored verifier that is useless to a thief):
Verifying a password (purpose: confirm the claim without ever storing the secret):
(1) Prevents duplicate passwords from being visible in the file — two users with the same password get different hashes because they have different salts. (2) Greatly increases the difficulty of offline dictionary attacks — for a salt of length b bits, the number of possible password+salt combinations is increased by a factor of 2b. (3) Makes it nearly impossible to tell whether a person reused the same password across systems — different salts yield different hashes even for an identical password.
Where / when / does it change? The salt is stored in clear in the password file, alongside the hash; it is generated at the moment the password is created or changed (a random/pseudorandom value); and it does not change over time for a given password — a new salt is only drawn when the password itself is changed.
Salt also defeats rainbow tables (§8): a precomputed table is tied to one hashing of each candidate, but per-user salt forces the attacker to recompute per user, which is the whole point of purpose (2).
Punchline: the hash hides the secret; the salt destroys economies of scale — the attacker can no longer crack many accounts (or many systems) for the price of one.
UNIX is the canonical implementation of "hashed + salted", and its evolution is a textbook arms race — learn the numbers verbatim.
| Scheme | Build | Salt | Output | Status |
|---|---|---|---|---|
Original crypt(3) | DES turned into a one-way hash; a zero value repeatedly encrypted 25 times; password up to 8 printable chars | 12-bit | 11-character sequence | Inadequate / broken |
| Improved (MD5, now SHA-512) | Unlimited password length; inner loop of 1000 iterations for slowdown | up to 48-bit (or more) | 128-bit hash | Replaced MD5 with SHA-512 |
| Bcrypt (OpenBSD) | Based on the Blowfish block cipher; configurable cost | 128-bit | 192-bit hash | Most secure version of the scheme |
Cross-link to Cyber-Cryptography: these all reuse symmetric primitives (DES, Blowfish) and a one-way hash — authentication storage is cryptography put to work. OpenBSD is the security-focused UNIX that introduced Bcrypt; its slogan-level priority is "proactive security and integrated cryptography".
Access control on the file. Even perfect hashing is wasted if anyone can read the file, so modern UNIX uses a shadow password file: hashes move to a separate file (/etc/shadow) readable only by privileged users, while user IDs stay in the world-readable /etc/passwd. This blocks offline guessing by denying the attacker the hashes in the first place.
A shadow file is necessary, not sufficient. The file can still leak via: (1) an OS weakness that bypasses access control; (2) a permissions accident making it readable; (3) password reuse on other systems the user controls; (4) backup media with weak physical security; (5) network sniffing of passwords in transit. Once the file is off the box, it is an offline problem — only strong hashing and good password selection (§9) still help. CIA: Confidentiality.
Punchline: slow, salted hashing plus a shadow file is the password store's only defense against offline cracking — each UNIX scheme tightens the same ratchet, but physical access to the file still beats cryptography, which is why selection strategy (§9) is the next line.
Given a stolen file, the attacker's job is to invert the hashes. Three approaches, increasing in sophistication:
Dictionary attack. Build a large password dictionary — common words, leaked passwords, and variations (backward spelling, appended digits/symbols, character substitutions) — and try each candidate. Crucially, each candidate must be hashed with each stored salt and compared, so salt makes this linearly more expensive per account. The same dictionary, used defensively, is what a proactive checker (§9) screens against. CIA: Confidentiality.
Rainbow table attack. Trade time for space: precompute a mammoth table of hash values so cracking becomes a lookup. It is countered by a sufficiently large salt and hash length — salt makes the table explode by 2b (purpose 2 again), which is why both the SHA-512 and Bcrypt schemes resist it for the foreseeable future. CIA: Confidentiality.
John the Ripper (JtR). The most famous open-source password-cracking tool, used both offensively and to defensively audit password quality. It runs four modes in escalating order of exhaustiveness:
rockyou.txt).Its speed is bounded by hardware — GPUs try billions of candidates per second, which is why offline attacks scale with money, not patience. (Dedicated GPU tools like Hashcat push this further; AI methods — Markov models, context-free grammars trained on breaches, and GAN-generated guesses — reorder the search toward likely passwords first.) CIA: Confidentiality.
Studies put passwords at fewer than 10 bits of security against online trawling and only about 20 bits against optimal offline dictionary attacks. An attacker allowed ~10 guesses per account compromises around 1% of accounts — small per attempt, large at population scale.
Punchline: GPUs made offline cracking cheap, so speed alone no longer protects you — only per-user salt (which defeats rainbow tables and shared work) and deliberate slowness (bcrypt's cost factor) still raise the attacker's price, proving why §6's salt was non-negotiable.
The problem. Every attack above feeds on guessable passwords, but users resist anything that hurts memorability. The goal of all four strategies: eliminate guessable passwords while letting the user keep something memorable.
| Strategy | How it works | Pro | Con |
|---|---|---|---|
| User education | Tell users why strong passwords matter; give selection guidelines | Cheap, trivial to deploy | Routinely ignored; users judge strength poorly |
| Computer-generated passwords | System assigns a random (sometimes pronounceable-syllable) password | Very strong against guessing — high entropy, dictionary-proof | Hard to remember → users write them down (feeding "user mistakes"/eavesdropping); poor acceptance; insecure if the RNG is weak or compromised |
| Reactive password checking | System periodically runs its own cracker and cancels any password it guesses | Finds weak passwords already in use | Resource-intensive; weak passwords stay exploitable until the next sweep finds them |
| Proactive password checking | System checks the password at selection time and rejects weak ones (user still chooses) | Best balance — eliminates guessable choices yet keeps user-chosen, memorable passwords | Must balance acceptability vs strength; too strict and users fight it |
Distinction (reactive vs proactive): both run the same kind of check, but reactive acts after a bad password is live (a window of exposure) while proactive blocks it before it ever exists — which is why proactive is preferred.
How a proactive checker decides: rule enforcement (e.g. minimum length and character-class rules), a password-cracker dictionary of forbidden choices (+ variations), or more sophisticated methods — neural-network strength evaluation, and invalidation against public breaches (e.g. a "Have I Been Pwned"-style API).
Two policies are roughly equivalent: basic16 (16+ characters) or comprehensive8 (8+ chars with upper, lower, digit, symbol, no dictionary words). Research found basic16 both stronger against large numbers of guesses and easier for users (passphrases). The caveat that makes it "reasonable but with a catch": a fixed length leaks information — the attacker can prune all shorter candidates from the search space.
Use the first letter of each word of a personal phrase — not "An apple a day keeps the doctor away" (Aaadktda), but "My sister Peg is 24 years old" → MsPi24yo. A password manager is the strong, low-memory alternative — provided you weigh its own threat model.
Punchline: four strategies, one arc — education alone fails (ignored), generation fails (unmemorable, written down), reactive fails (a window of exposure until the next sweep), and only proactive succeeds by blocking bad choices at selection time, trading a little signup friction for guessability eliminated at the source.
The problem tokens solve. Passwords fail at the human vulnerability: people forget, reuse, and write secrets down. Token-based authentication answers this by moving the secret out of fragile human memory and onto an object the user carries — a person holds the secret on plastic instead of in their head. The trade is a new vulnerability: a physical asset that can be lost, stolen, or copied. Concrete example: a bank ATM combines the card (token) with a PIN (something you know) precisely so that losing one factor does not grant access. Two families:
Memory cards — store but do not process data; the classic example is the magnetic-stripe bank card. Fine alone for low-stakes physical access (hotel rooms), but for anything serious they are combined with a PIN/password (ATM = card + PIN) — two factors. Why not alone? The data is often stored in clear, so a simple theft or copy grants access. CIA: Confidentiality / Integrity. Drawbacks: needs a special reader, the token can be lost, and the data is in clear.
Smart cards — carry an embedded microprocessor (processor + ROM/EEPROM/RAM + I/O, sometimes a crypto co-processor), so they process data, not just store it. The decisive difference from a memory card: the secret is processed inside the card — the terminal receives only a yes/no, never the secret — enabling protocols a memory card cannot run.
Smart cards are classified on several axes; the two that get tested:
Electronic interface — contact vs contactless: a contact card is inserted so its gold-plated contacts touch the reader; a contactless card communicates by radio frequency via an embedded antenna, needing only proximity (~0.5–3 inches) and drawing power from the field — ideal where speed matters (transit, payments).
Authentication protocol — three types (this is the high-value enumeration):
Punchline: memory cards move the secret onto plastic; smart cards keep the secret on the plastic and only ship proofs — the same leap as storing a hash instead of a password.
The problem biometrics solve (and the one they create). Passwords are guessable and tokens are losable; a biometric is neither — it cannot be guessed and is always carried. But it adds a new vulnerability: permanence. A stolen biometric cannot be reset the way a password can. Concrete example: iPhone Face ID is a static biometric — convenient, but if the underlying template were ever compromised you cannot reissue your face.
Biometric authentication identifies a person by a physical or behavioral characteristic and, unlike a password, rests on pattern recognition — samples almost never match exactly, so the system decides on closeness, which forces a trade-off between false matches and false non-matches.
Seven biometric traits span a cost/accuracy spectrum: Face (lower accuracy, low cost), Fingerprint (high accuracy, medium cost), Hand geometry (lower accuracy, low cost), Iris (very high accuracy, high cost), Retina (high accuracy, high cost), Signature (behavioral, low cost), and Voice (behavioral, low cost):
This maps back to the four means: fingerprint/retina/face are static ("is"); voice/handwriting/typing rhythm are dynamic ("does") and harder to spoof because the trait varies naturally.
A biometric system runs three operations — keep the 1:1 vs 1:N distinction sharp:
A biometric is not a password: it cannot be reset if stolen. Theft of the template is a permanent compromise (a host attack, §13), and the trait can be copied/spoofed (eavesdropping). CIA: Confidentiality / Integrity.
Punchline: biometrics swap a resettable secret for a permanent signature — template theft is forever, spoofing risk varies by trait, and 1:N identification quietly turns authentication into search, which is why a biometric is a strong second factor but never safe alone.
The problem. Remote user authentication — authentication over a network, the Internet, or a communications link — is harder than local because the wire itself is hostile. It adds three threats absent locally: eavesdropping, capturing a password, and replaying a recorded authentication sequence. As noted in §5, encrypting the password fails because the ciphertext becomes a replayable secret. The chain here is explicit: the vulnerability is an untrusted wire; the solution is to never send the secret at all — send a one-time proof instead. The general answer is a challenge-response protocol. Concrete example: SSH and TLS client authentication use exactly this pattern — the server sends a fresh challenge and the client returns a value computed from it, so a wiretapper captures a proof that is useless next session.
Purpose / CIA target: prove possession of the secret without sending it and make each exchange unrepeatable — defending Confidentiality (secret never transmitted) and Integrity/authenticity (replays rejected).
The basic password challenge-response, as ordered steps:
h() (a hash) and f() to use — this transmission is the challenge.f(r', h(P')), where r' = r (the returned nonce) and P' is the entered password — i.e. a function of the nonce and the hash of the password.h(P(U)), computes f(r, h(P(U))) and compares. If the two match, the user is authenticated.(1) The host stores only the hash, not the password — protects against host/file theft. (2) Not even the hash is sent directly; it is buried as an argument of f() — the secret cannot be captured on the wire. (3) The fresh nonce makes every response one-time — a captured response is useless next session, which is precisely what defeats replay.
The same shape generalizes to the other means: for a token the response is f(r', h(W')) over the passcode W'; for a biometric the client returns the encrypted nonce + template (e.g. E(r', D', BT')) and the host checks r' = r and the template — one pattern, four means. (Cross-link: the nonce here is the same anti-replay idea as the nonce-vs-timestamp freshness device in Cyber-Cryptography; the asymmetric variant is the same public-key crypto used by passkeys in §14.)
Punchline: challenge-response is the master pattern for remote proof — the nonce defeats replay (each response is one-time), the hash defeats capture (the secret never travels bare), and cryptography defeats eavesdropping; the attacker walks away with a proof, never the secret.
This is the chapter's chain seen whole: the same goal (defeat the gate) struck at different points. Keep the six categories countable, each with its CIA consequence and its typical defense.
admin/admin or a rockyou.txt wordlist. Defense: large entropy + limited attempts (and, for tokens, physical possession is also required). CIA: Integrity (an impostor accepted as authentic).Client vs host, sharpened: both end in impersonation, but a client attack works "from the front" (guessing at the login, no inside access) while a host attack works "from behind" (stealing the credential store). That is why their defenses differ: client attacks are starved by entropy + attempt limits; host attacks are starved by hashing + access control.
Punchline: read the table as one map — secure the file (host), the wire (eavesdrop/replay), the human (eavesdrop/Trojan), and the front door (client/DoS); a single gap re-opens the gate.
Multi-factor authentication (MFA) uses more than one of the four means; implementations using two factors are stronger than one, three stronger than two — this is defense in depth / layering applied to the gate: cracking one layer (the password) still leaves the next. A typical two-step flow: step 1 something you know (username + password); step 2 something you possess (a dynamic PIN from a device, or a one-time code).
The second factor's strength depends on in-band vs out-of-band. In-band = both factors entered through one device (e.g. a PC); if that device is compromised, both factors fall — the "two factors" collapse into one. Out-of-band uses an independent channel. NIST has deprecated SMS for out-of-band verification ("will no longer be allowed in future releases of this guidance") because SMS is vulnerable to SIM-swapping. CIA: Confidentiality / Integrity.
Passkeys are the next step, aiming to replace usernames and passwords entirely. They are built on public-key cryptography (key pairs — same primitive as Cyber-Cryptography's digital signatures): the private key is stored on the local device, not a remote server, which blunts server-side breaches (nothing reusable to steal). They are phishing-resistant because each passkey is bound to the specific app/site it was made for, and a biometric (fingerprint/face) authorizes its use — quietly combining factors. They can sync across devices, with the security caveats that implies.
Passkeys are only partially deployed, with real interoperability limits, and — because they fold in biometrics — raise legal questions, since biometric authentication can carry different legal protection than a password. As always: consider the threat model before declaring victory.
Punchline: single-password authentication is one secret on one channel — convenient, cheap, and increasingly inadequate; the trajectory of the whole chapter is from one fragile secret toward layered, replay-proof, server-secret-free proof.
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.