Credential attacks do not all work the same way. One actor may guess passwords through a live login screen, another may try one common password across hundreds of accounts, and another may replay usernames and passwords exposed at an unrelated service. An attacker who has obtained password hashes can test guesses offline without sending any sign-in requests. The distinctions determine which controls can actually interrupt an attempt and what evidence responders should expect to find.
The common feature is an attempt to obtain or use credentials without authorization, but a credential attempt is not automatically a successful account takeover. Attackers can also use social engineering to persuade people or help desks to bypass normal verification. An effective security assessment identifies the authentication path, the information the actor already knows, the business consequence of success and any alternative recovery or session path.
Separate online guessing from offline password cracking
Online guessing sends proposed credentials to an authentication service. The defender can observe failures, apply progressive delays, enforce request limits, challenge a suspicious sign-in or block an account or source temporarily. These controls have availability costs: an attacker may deliberately exhaust lockout thresholds and deny legitimate users access. A rate-limiting policy must therefore be evaluated against both unauthorized attempts and accidental or malicious account denial.
Offline cracking begins after an adversary obtains verification material, usually a database of password hashes or other credential artifacts. Login rate limits do not constrain computation on the attacker’s systems. Password hashing protects stored secrets only when the verifier uses an appropriate one-way, salted and deliberately expensive password-hashing design. A fast unsalted hash is a different risk from a password hashed with a properly configured memory-hard scheme; no single “guesses per second” figure describes both.
Passwords cannot be made safe solely by demanding unusual symbols or frequent predictable changes. Verifiers should block commonly used and compromised passwords during creation or change, support sufficiently long passwords and avoid arbitrary composition rules that induce memorable patterns. Administrators should protect backups containing password verifiers, control access to identity stores, detect suspicious export events and have a credential-reset and incident-communications plan before a breach.
Distinguish stuffing, spraying, dictionaries and exhaustive search
Exhaustive guessing enumerates candidate values until a correct one is found or resources run out. Dictionary-based guessing prioritizes familiar phrases, predictable substitutions or previously seen passwords. These methods may target a single identity online or be used against an offline verifier. The quality of candidate selection matters, but a weak-password assumption is not evidence that a particular target is already compromised.
Credential stuffing uses known username-and-password pairs, commonly obtained from a breach elsewhere, against a new service. It primarily exploits reuse rather than discovering an unknown password by trying arbitrary strings. The application being attacked may have stored its own password hashes correctly and still be exposed because customers reused credentials at an unrelated website. Unique credentials and appropriately implemented phishing-resistant authentication are therefore central defenses.
Password spraying tries one or a few common passwords across many identities, often pacing attempts to avoid per-account thresholds. This pattern differs from intense guessing against one username, though both may appear within the same campaign. Defenders should correlate authentication outcomes across accounts, applications and source networks. A distributed low-rate spray may not trigger an alert tied to one IP or one user, and shared residential or enterprise IP addresses make indiscriminate blocking unreliable.
Identify the actual exposed sign-in surface
Inventory public account portals, remote access gateways, administrative consoles, SSH or RDP endpoints, identity-provider interfaces and APIs that accept credentials. Some systems are deliberately reachable from the internet, but reachability is not a reason to expose privileged authentication without additional controls. Review legacy protocols, machine identities, emergency accounts and vendor-operated access that may bypass the main single sign-on policy.
A virtual private network may protect the transport of a remote user’s traffic while leaving the VPN login itself exposed to guessing. VPN use does not automatically provide phishing-resistant authentication, safe device posture or authorization to every internal network. Remote-access controls should be assessed separately for connection security, sign-in resistance and what a successful account can actually reach.
Focus on consequence rather than the number of public hosts alone. A low-privilege test account and a production backup administrator have different risk profiles. Document which accounts can enroll authenticators, create persistent API tokens, reset other users, access payment functions or modify recovery infrastructure. Reducing unnecessary privilege can substantially lower the impact of a guessed or reused credential even when sign-in detection is imperfect.
Use rate controls without creating an avoidable outage
Online authentication should apply effective rate limits and use additional signals when a sign-in is risky. Per-account, network and device evidence can supplement one another; none is sufficient alone. Progressive delays and temporary friction may be preferable to aggressive permanent lockouts for some consumer systems. A protected administrative portal may justify stricter access controls and escalation paths. Test thresholds with both actual user patterns and authorized attack simulations.
Bot and abuse detection can evaluate attempt velocity, sessions, endpoint behavior and changing source addresses, but false positives matter. Corporate NAT gateways, mobile carriers, users with assistive technology and legitimate automated clients may share patterns with abusive traffic. Require an owner to monitor unsuccessful challenges and help-desk impact. Security that blocks legitimate account access indefinitely can become its own denial-of-service incident.
Do not assume that a correctly throttled password endpoint protects the complete identity workflow. Account recovery, forgotten-password requests, new-factor enrollment and help-desk overrides may offer different routes to the same identity. Keep these paths within the same risk assessment and alerting plan so an attacker cannot abandon a difficult login and succeed through a weaker alternate route.
Protect password reuse, authenticators and account recovery
Users should be able to create distinct passwords for each service, ideally with a reliable password manager. Organizations should screen new passwords against compromised and commonly used choices without forcing arbitrary periodic changes in the absence of a reason. A password reset after a confirmed breach should include a review of reuse elsewhere, session validity, registered devices and recovery settings where the organization has authority and visibility.
Multi-factor authentication reduces the usefulness of a stolen password, but methods differ. One-time codes can be phished, approval pushes can be coerced, and a help desk may be persuaded to enroll an unauthorized replacement factor. FIDO2/WebAuthn authenticators bind authentication to the legitimate relying party when correctly implemented; session handling, enrollment and recovery still require independent safeguards. Enrollment notifications and strong authorization for factor changes help expose a takeover attempt that is no longer targeting the password itself.
Service accounts and API credentials require a different path. Password vaults, scoped permissions, machine-identity rotation and secret management may be more appropriate than interactive MFA. Inventory long-lived credentials, remove unused access, restrict where secrets can be retrieved and verify that rotation actually propagates to consuming services. A policy that applies only to employees’ browser logins leaves other credential surfaces unexamined.
Investigate the sequence rather than a dramatic dashboard number
Sign-in logs should preserve account, application, timestamp, outcome, authentication method and available device or network context, subject to privacy and retention controls. Correlate bursts of failures with successful sessions, newly registered authenticators, unfamiliar token grants, privileged changes and unusual data access. A large number of blocked attempts does not establish that the attacker entered the system; a single confirmed unauthorized session can matter more than thousands of failures.
When compromise is suspected, preserve the relevant evidence, identify the affected identity and determine what it could access. Appropriate actions may include invalidating sessions, rotating compromised credentials, revoking issued tokens, protecting recovery methods and checking subsequent actions. Scope and communicate the incident based on confirmed evidence; do not describe all failed login traffic as exfiltration or successful penetration. Track containment effectiveness through observable changes, not only an abrupt decline in dashboard counts.
Detection tuning should cover distributed patterns as well as obvious high-rate attacks. Compare failures across identities and services over meaningful time windows, and validate whether alerts are routed to responders who can act. Run authorized exercises that include a low-rate spray, reused credential, account recovery attempt and unrelated legitimate lockout. Record which control blocked the sequence and which evidence would be available after an actual incident.
Evaluate claims that brute-force attacks are increasing
Credential attacks are a persistent exposure, but a broad claim that they are universally rising requires comparable evidence. Provider reports may count blocked requests, unique usernames, bot traffic, attacks per tenant or confirmed account takeovers. These measurements are not interchangeable. An observed increase might reflect a larger customer population, better sensors, a changed definition or a real change in attacker behavior. State the source, period and denominator before describing a trend.
Similarly, a list of leaked credential pairs does not establish how many unique people are compromised or how many accounts still use valid passwords. Offline hash-cracking estimates depend on the verifier and the tested hardware; online attack rates depend on endpoint controls. A meaningful security report distinguishes attempted and successful activity, the assets at risk and what changed after a defensive improvement rather than presenting a single global “brute-force growth” number.
For a specific organization, repeat the same measurable observations across comparable periods: attempted sign-ins by method, confirmed account takeovers, blocked compromised-password enrollment, challenge false positives and time to revoke sessions. Document changes in instrumentation or application population. This produces a defensible local trend even when broader public statistics cannot be applied to the environment.
Prioritize protections by the attacker’s available path
For online guessing, implement suitable rate limiting, monitored authentication and resilient account availability. For spraying, correlate attempts across identities and remove predictable passwords. For stuffing, reduce reuse and protect recovery flows. For offline cracking, strengthen password verifier storage and restrict access to credential databases and backups. For every path, examine what an unauthorized session could do and how quickly it can be disabled.
The durable lesson is not that every credential attack is increasing or that one tool guarantees protection. It is that distinct attack mechanisms need distinct evidence and safeguards. Inventory exposed sign-ins, require strong authentication where the consequence warrants it, verify account recovery and response, and measure outcomes with definitions that can be compared over time.
