Why Hackers Still Love Passwords: Modern Credential Defense

Cybersecurity

Updated July 12, 2026

By Jerame Trunnell Owner of Cloud Core MSP

Hackers still love passwords because a credential is more than a string. It is an entry point into sign-in, account recovery, MFA enrollment, browser sessions, help-desk verification, application consent, and privileged access. Attackers do not need to crack every password if they can reuse one, spray a common value, persuade a person to approve a prompt, steal an authenticated session, or reset the account through a weaker process.

The practical defense is therefore not another annual reminder to "make passwords complex." It is a credential system that resists common attacks, limits the value of stolen material, protects recovery, detects abnormal use, and lets responders revoke access quickly. MFA remains important, but it is not infallible and different methods resist different attacks.

Password policy has changed because attack paths changed

NIST SP 800-63B-4 authenticator guidance says passwords are not phishing-resistant. It emphasizes adequate length, checking new passwords against a blocklist of common or compromised values, allowing password managers and paste, and avoiding arbitrary composition rules. Apply NIST's requirements according to the assurance context and the systems you operate rather than copying one number into every legacy application.

Long, unique passwords stored in a reputable password manager make guessing and reuse harder, but they do not stop a convincing counterfeit sign-in page from capturing the password. Nor do they protect a browser session that has already completed authentication. Treat password quality as one layer in a larger authentication and session design.

Modern attacks target MFA and sessions too

Push-based MFA can be abused through repeated prompts or social pressure. CISA's number-matching guidance describes number matching as an interim mitigation for MFA fatigue when phishing-resistant MFA is not yet available. A user who receives an unexpected prompt should deny it and report it through a known channel; the organization should investigate the initiating sign-in rather than praise the denial and move on.

Adversary-in-the-middle (AiTM) phishing proxies the interaction between the user and the real service. Microsoft documented campaigns that captured credentials and authenticated session cookies, enabling follow-on access even when the victim completed MFA in its AiTM analysis. Infostealers and endpoint compromise can also expose browser tokens or cookies. This is why incident containment may require session revocation, token and application review, endpoint investigation, and credential reset rather than a password change alone.

Phishing-resistant authentication reduces relay risk

NIST SP 800-63B-4 explains that manually entered one-time codes are not phishing-resistant because an impostor can relay them to the real verifier. Cryptographic authenticators can bind authentication to the legitimate service. Passkeys use public-key credentials and are designed for phishing-resistant sign-in; the FIDO Alliance passkey overview explains that passkeys may be synced or device-bound and that the private key is not shared with the service.

Passkeys are a strong direction, not a complete identity program. Enrollment, device security, synchronization, fallback authentication, account recovery, offboarding, and administrator access still need governance. If a user can bypass a passkey by calling a help desk with weak proof, the recovery path becomes the preferred attack path.

Use the credential attack and control matrix

Create one risk ID for each material attack path in every critical identity platform and account class. Complete both parts of the register under the same risk ID. Do not mark a control implemented because a product can support it; link the operating configuration, test, or review evidence.

Part A: attack, prevention, detection, and response

Risk ID	System / account class	Attack path	Preventive control	Detection	Response
CRED-01	Identity platform / workforce accounts	Password spray or credential stuffing	Unique managed passwords, compromised-value blocklist, rate controls, risk-based policy, no shared accounts	Distributed failures, new source or device, successful sign-in after failures	Block activity; review affected identities; revoke sessions; reset only through verified recovery; preserve evidence
CRED-02	Help desk / privileged and finance accounts	Reset or recovery social engineering	Documented identity proofing, authoritative callback, separation for privileged resets, staff rehearsal	Recovery-detail change, unusual urgency, repeated resets, new authenticator enrollment	Stop reset; preserve request; verify independently; remove unauthorized methods; review downstream access
CRED-03	Cloud sign-in / MFA-enrolled accounts	MFA fatigue or prompt bombing	Phishing-resistant method where feasible; number matching as an interim control; contextual prompts; user reporting	Repeated denials, prompts without user sign-in, new location followed by approval	Restrict account; revoke sessions; investigate initiating device and sign-ins; restore verified methods
CRED-04	Email and SaaS / workforce and administrator accounts	AiTM phishing and session theft	Phishing-resistant authentication, managed devices, sign-in conditions, web and endpoint protection	Unfamiliar session properties, mailbox or forwarding changes, impossible sequence, token reuse	Revoke sessions and tokens; contain endpoint; reset credentials; review consent, rules, roles, and accessed data
CRED-05	Managed endpoint / interactive user accounts	Infostealer or browser-cookie theft	Endpoint hardening, patching, least privilege, browser control, application isolation as appropriate	Malware alert, session use from new infrastructure, credential or cookie artifacts	Isolate and investigate device; revoke cloud sessions; rotate exposed credentials; reestablish trust before reconnecting
CRED-06	Identity recovery / passkey-enabled accounts	Passkey enrollment or recovery abuse	Strong enrollment and recovery proofing, alerts, authenticator inventory, protected administrator recovery	New passkey or recovery change outside expected workflow	Remove unknown authenticator; revoke sessions; validate identity and devices; examine recovery and audit events
CRED-07	Business applications / vendor, service, and privileged accounts	Stale ownership or excessive access	Named owner, least privilege, expiration, workload-identity or managed-secret pattern, periodic access review	Use after contract or employment event, credential age, owner missing, privilege change	Disable safely; revoke and rotate; identify dependencies; review actions; correct lifecycle source and workflow

Part B: ownership, implementation, evidence, and review

Risk ID	Control owner	Implementation status	Exception	Evidence location	Last test	Next review	Response contact
CRED-01 through CRED-07	One accountable role or person, not a department alone	Not started, designed, partially implemented, implemented and tested, or accepted risk	Deviation, reason, compensating control, approver, and expiration; enter "none" when absent	Configuration export, policy, ticket, alert result, access review, or exercise record	Date, test method, result, and tester	Date or triggering event for the next control review	Monitored team or on-call role with an approved contact path

Duplicate the Part B row for every risk ID and system instance. When one control differs by account class, retain separate records rather than hiding the exception in a general note. The register becomes useful when it drives tickets, alert tests, access reviews, and response exercises rather than living in a policy attachment.

Protect password reset and identity recovery

Reset workflows deserve the same design attention as sign-in. Define which evidence is accepted, which channels are prohibited, when a second approver is required, and how a requester is contacted through a previously established path. Do not ask staff to disclose an existing password or MFA code. Alert the account owner when credentials, authentication methods, recovery details, privileged roles, or forwarding rules change.

For administrators, use separate day-to-day and privileged identities, stronger phishing-resistant methods where supported, limited standing privilege, and protected emergency access. CISA's identity and access management practices for administrators cover phishing-resistant MFA, account separation, auditing, and privileged-access protections.

Respond to a suspected credential compromise completely

Use a known channel to confirm the report and identify affected identities, systems, devices, and time range.
Contain active access with the identity platform's supported account, session, token, credential, and application controls.
Preserve relevant identity, endpoint, email, admin, application-consent, and recovery logs before retention windows close.
Investigate the endpoint and follow-on changes, including mail rules, new authenticators, role grants, application consent, data access, and payment activity.
Reestablish the user's identity through the approved recovery process, issue appropriate authenticators, and restore access from a trusted device.
Document scope, decisions, notification analysis, corrective controls, owner, and validation date.

Microsoft's cloud token-theft guidance describes both AiTM and pass-the-cookie techniques and reinforces why token response is distinct from a password reset.

Measure control operation, not user blame

Useful measures include critical identities covered by the intended authenticator policy, privileged and vendor accounts with current owners, stale accounts removed within the organization's target, unexpected authenticator changes investigated, session-revocation exercises completed, and corrective actions closed. Review exceptions by age and business owner. Do not publish a misleading "MFA protected" percentage that counts weak enrollment, unenforced policy, recovery gaps, and dormant accounts as equivalent.

CISA's More Than a Password guidance recommends MFA and points organizations toward phishing-resistant methods, with number matching when stronger methods cannot yet be implemented. Prioritize the most consequential identities first: administrators, email, remote access, finance, HR, backup, security tools, and anyone who can reset or grant access.

Related identity guidance

Use the credential-abuse prevention guide to design the wider identity program, the modern phishing guide for user and technical defenses, and the zero trust guide to place authentication inside resource-access decisions. The matrix on this page should remain the system-specific control and response record.