Why do credential stuffing and phishing still work against online banking?

Why credential stuffing keeps working

credential stuffing works because online banking still has to accept login attempts from the real world, where people reuse passwords and attackers can test stolen username-password pairs at scale. The attack does not need to break banking encryption or bypass the bank’s perimeter. It only needs a reused secret, a path to automate retries, and a recovery process that does not stop account takeover fast enough.

Banks have improved rate limiting, bot detection, and step-up controls, but those controls are uneven when the attacker spreads attempts across many devices, IPs, and credential pairs. When a reused password is valid, the attacker often arrives as a normal-looking login, which makes the difference between “failed noise” and “real compromise” mostly a matter of detection quality and authentication strength.

A second reason is that recovery often becomes the weakest path. If a bank allows password resets, device re-enrolment, or help desk overrides with signals that are easier to fake than the primary login, the attacker can move around the login screen entirely. The problem is not only password reuse, but also the institution’s fallback paths when the primary factor fails.

Modern password guidance from Password Security and Password Manager Guide is relevant here because the practical answer is not “make passwords harder to type”, it is “make stolen passwords less useful”. That usually means blocking known-breached passwords, discouraging reuse, and reducing how often a password alone can lead to a valid session.

Why phishing still defeats customers and session controls

Phishing still works because the attacker targets the human and the session, not just the password. A customer who types credentials into a fake page can hand over the primary secret directly, and if the bank still uses one-time codes, push approvals, or weak recovery callbacks as the main fallback, the attacker can capture or relay enough information to continue the session in real time.

The more the authentication flow depends on a secret that can be observed, copied, or relayed, the more phishing can succeed without any malware on the device. That is why phishing-resistant authentication matters. Passkeys, hardware-backed authenticators, and origin-bound verification change the attack from “steal a code” to “defeat cryptographic binding”, which is a much harder problem for the attacker.

Online banking often also has transaction and device context that could block abuse, but those signals must be used consistently. If the bank only checks the login event and not device changes, destination changes, unusual transfer size, or impossible travel, the attacker can inherit a valid session and behave like the customer long enough to move money or add a new payee.

The NIST SP 800-63 Digital Identity Guidelines are useful here because phishing resistance, authenticator strength, and reauthentication decisions are central to whether a banking session survives social engineering. The point is not to eliminate all phishing, but to make stolen login material insufficient on its own.

What banks usually need to fix first

The core issue is not one control, but the chain from login to recovery to transaction approval. If any one of those links can be socially engineered, replayed, or reset too easily, attackers will route around the strongest step. Banks therefore need to treat authentication, recovery, and step-up checks as one security system rather than separate product features.

Customer IAM (CIAM) Guide is a practical fit because it covers the controls that stop account takeover, including phishing-resistant MFA, secure recovery, and risk-based step-up. That mix matters in banking because customers need low-friction access, but fraud teams need enough friction to stop an attacker who already has partial credentials.

Where banks still depend on reusable secrets, the attack surface also expands through support channels, SMS codes, and reset workflows. The Guide to the Secret Sprawl Challenge is relevant as a control-pattern reference because the same operational mistake appears here: too many valid secrets, too many places to capture them, and too many ways to use them after theft.

For readers who want a broader identity-control baseline, Workforce Identity Security Guide is still useful for the same reason phishing wins in practice: session theft, help desk resets, and weak recovery are recurring failure points across identity systems, even when the target population is customers rather than employees.

Risk and Threat Considerations

Credential stuffing and phishing remain effective because they scale cheaply against controls that still assume one user, one device, and one trusted recovery path. Once an attacker has a valid session, the risk shifts from login failure to transaction abuse, payee manipulation, and account persistence, which can be harder to detect than the original theft.

Failure mechanism: Reused passwords, relayed one-time codes, and weak recovery flows let the attacker satisfy enough of the bank’s authentication logic to obtain a legitimate session or reset path.

Impact: The attacker can bypass the visible login boundary, steal funds, change contact details or payment destinations, and keep access even after the customer notices the phishing attempt.

Practitioner Guidance

What to prioritise: Treat phishing-resistant authentication and secure recovery as the first-line anti-fraud controls, not optional hardening. If a customer can still regain access through a code, callback, or help desk path that an attacker can socially engineer, the primary login control is only partially effective.

What to verify: Check whether the bank challenges risky logins and risky transactions differently. Good banking control design uses device, session, and transaction signals together, so a successful login does not automatically equal transfer authority.

Common mistake: Many teams over-focus on login success rates and under-focus on post-login abuse. A well-run attack often looks like a normal customer session until the attacker changes the destination account or initiates the transfer.

Practitioner takeaway: If reusable secrets can still unlock money-moving capability, the real control gap is not just authentication strength, it is the bank’s ability to keep stolen access from becoming trusted, transactable access.

Related resources from NHI Mgmt Group

• Why do credential stuffing attacks still work when 2FA is enabled?
• How should security teams use proof of work against credential stuffing?
• Why do credential stuffing attacks still succeed against consumer identity systems?
• Why does credential phishing still work in organisations with mature email security?