Recently, I switched to another bank, and after setting up the online banking credentials and trying...

Recently, I switched to another bank, and after setting up the online banking credentials and trying to log in for the first time, I found a form similar to this one.

The system requests characters in random positions each time I log in, which is quite interesting. Passwords are supposed to be stored as salted hashes, and with that, only the full password can be verified. So, what is happening here?

Advantages

Partial password authentication was adopted mainly in response to a combination of security threats and regulatory pressure, primarily in the U.S. and Europe during the early-to-mid 2000s.

Keystroke Logging Malware

Keystroke Logging Malware was a major catalyst due to the rise of keyloggers that recorded every keystroke. If a user entered their full password, attackers could capture it completely. Partial password entry countered this by only requesting certain characters, so even if a keylogger captured them, it wouldn't have the full password, and the next login would require different positions.

Shoulder Surfing Protection

Shoulder surfing protection functions similarly. Observers or cameras only capture a few characters per session, requiring multiple observations to track the requested positions each time.

Phishing Mitigation

Phishing mitigation is subtle but effective. If a fake site asks for your full password, it gains everything. However, if the real bank only requests partial characters, a phishing site must either ask for the full password, which should alert users, or request a few characters, limiting what they capture. It's not foolproof, but it increases security.

Backend Implementation

With standard password authentication, you store a salted hash (e.g., bcrypt) and compare. But hashing is a one-way, all-or-nothing operation — you can't verify the 3rd character of a password from a bcrypt hash. So partial password verification requires a fundamentally different storage and verification strategy.

1. Encrypted Plaintext Storage

The most straightforward approach. You store the password encrypted (not hashed) using a symmetric key (e.g., AES-256), managed via an HSM or a secrets manager.

Verification flow:

1. Server generates a random set of character positions (e.g., positions 2, 5, 8).
2. User submits those characters.
3. Server decrypts the stored password, extracts the characters at those positions, and compares.
4. Plaintext is discarded from memory immediately.

Tradeoffs:

Simple to implement, but the password is technically recoverable. If the encryption key is compromised, all passwords are exposed. This is why the key must live in an HSM with strict access controls. Many UK banks use this model.

2. Store Individual Character Hashes

You hash each character (or each character + its position) independently and store them all.

For a password s3cur3, you'd store something like:

position_0: hash("s" + salt + "0")
position_1: hash("3" + salt + "1")
position_2: hash("c" + salt + "2")

Verification flow:

1. Server picks random positions, sends them to the client.
2. User submits the characters.
3. Server hashes each submitted character with the corresponding positional salt and compares.

Tradeoffs:

No reversible encryption is needed. However, each character hash has a small keyspace, making brute-force attacks easy unless a costly hash function (like high-cost bcrypt or Argon2) is used per character. Even then, attackers with the database can crack positions offline with some effort. Using an HSM-held pepper can make offline attacks infeasible without it.

3. Shamir's Secret Sharing / Threshold Schemes

A more cryptographically elegant approach. You treat the password (or a key derived from it) as a secret and split it into shares using a threshold scheme.

Setup:

1. User registers with full password.

2. Server derives a secret from the password and splits it into n shares (one per character position) using a (k, n) threshold scheme, where k is the number of characters you'll challenge.

3. Shares are stored server-side.

Verification flow:

1. Server challenges the user for k positions.

2. Each correct character allows reconstruction of the corresponding share.

3. If k valid shares are provided, the secret is reconstructed and verified against a stored hash of the secret.

Tradeoffs:

Mathematically strong — fewer than k correct characters reveal zero information about the secret. But it's complex to implement correctly, and key management during registration is critical.

4. Pre-computed Challenge-Response Sets

At registration, you pre-generate all (or many) possible challenge combinations and store a hash for each.

For example, if you always ask for 3 of 10 characters, there are C(10,3) = 120 combinations. For each combination, you concatenate those characters and store a salted hash.

Verification flow:

1. Server picks a combination, looks up the corresponding hash.
2. User submits the characters.
3. Server hashes the submission and compares.

Tradeoffs:

You get proper hashing (bcrypt/Argon2) with no reversibility. But storage grows combinatorially. For 3 of 10, 120 hashes is manageable. For 4 of 20, it's C(20,4) = 4,845 — still feasible but heavier. Each hash needs its own salt, and password changes require regenerating the entire set. This is arguably the best balance of security and functionality for moderate password lengths.

Is it Still Relevant?

Honest answer: partial password authentication is a legacy technique that's being actively phased out. It was already niche (primarily UK banks and a few European financial institutions), and the industry has moved decisively past it.

Why it's dying out

The fundamental problem is that partial passwords solve a narrow threat (keyloggers capturing the full password in one session) while introducing significant backend complexity and weaker security properties compared to modern alternatives. Every design we discussed requires either storing passwords reversibly, dealing with tiny per-character keyspaces, or managing combinatorial storage — all of which are worse trade-offs than what's now available.

What replaced it

The shift is toward eliminating shared secrets entirely. Passwords are responsible for 80% of data breaches, and passwordless authentication removes that attack surface. Here's what the landscape looks like now:

Passkeys (FIDO2/WebAuthn)

The clear winner. They use asymmetric cryptography — a private key stays on the user's device, a public key sits on the server. There's nothing to phish, nothing stored server-side that's useful to an attacker, and nothing for the user to remember. As of Q1 2026, over 340 million banking customers worldwide authenticate using passkeys or other FIDO2-compliant methods, with adoption accelerating 180% year-over-year. Major banks have gone all-in: HSBC launched passkey authentication across 14 markets simultaneously, achieving 41 million passkey users — a 60% adoption rate in just six months. Nordea became the first bank to fully deprecate password authentication, and as of January 2026, new customers can only set up passkey authentication.

Regulatory pressure is making this mandatory, not optional.

The UAE Central Bank issued a directive requiring all financial institutions to eliminate SMS and email OTPs by March 2026. NIST's SP 800-63-4 now requires that multi-factor authentication must offer a phishing-resistant option, and AAL3 requires hardware-backed non-exportable private keys. India, the Philippines, and the EU all have similar deadlines landing in 2026.

Device-bound biometrics (fingerprint, face recognition) serve as the local unlock for passkeys. The user taps their fingerprint to release the private key — no secret ever crosses the network. Microsoft found that passkey sign-ins take only 8 seconds on average, compared with 69 seconds for traditional password plus second factor.

Adaptive/risk-based authentication layers on top, evaluating contextual signals like device, location, and behavior patterns to dynamically adjust requirements without adding user friction.

Partial password authentication was a clever workaround when keyloggers were a major threat and stronger alternatives were unavailable. Each backend design balanced simplicity, cryptographic rigor, and infrastructure trust, but all shared a weakness: the server held something worth stealing. In 2026, passkeys have rendered this obsolete by eliminating shared secrets at the protocol level—nothing sensitive is stored server-side, nothing useful crosses the network, and nothing needs memorizing. With regulatory mandates enforcing phishing-resistant authentication and over 340 million banking customers using FIDO2/WebAuthn, partial passwords are now a historical curiosity. Today, the solution is passkeys—offering the cryptographic elegance that Design 3 aimed for, but delivered natively.