What is an offline guessing attack?
An offline attack happens when an attacker can test password guesses on their own hardware without sending each guess to a website. Website rate limits, account lockouts, CAPTCHA challenges, and login alerts do not slow this type of attack. The attacker can test large dictionaries, leaked-password lists, common phrases, and predictable variations as quickly as the derivation process allows.
Why fast hashes require stronger secrets
SHA-256 is a respected cryptographic hash, but it was designed to be fast. Speed is useful for integrity checks and many cryptographic systems, yet it also lets an attacker test guesses quickly. Password-specific derivation functions such as Argon2, scrypt, and properly configured PBKDF2 deliberately make each guess more expensive.
Kardix currently uses browser-native SHA-256 for deterministic generation. Therefore, its protection depends heavily on a long, unpredictable passphrase and any optional secret input. The public algorithm should never be treated as a hidden defense.
What attackers guess first
- Previously leaked passwords and phrases.
- Names, dates, places, teams, films, pets, and family information.
- Popular quotations and song lyrics.
- Keyboard patterns and repeated characters.
- Word combinations with predictable numbers or symbols.
Adding one familiar year or an exclamation mark usually does little because cracking tools automatically test those transformations.
How to reduce the risk
Use a genuinely random multi-word passphrase with enough length to remain outside realistic guessing lists. Keep service labels consistent but do not consider them secret. Where Kardix offers an additional password, choose an independent value that is not a fragment of the main passphrase.
Protect the device as well. Disk encryption, operating-system updates, a clean browser profile, and cautious extension use help prevent malware or local attackers from reading inputs before hashing occurs.
Online attacks are different
When an attacker must submit guesses to Google, a bank, or another service, rate limits and multi-factor authentication can slow or stop the attack. However, those protections do not strengthen the master passphrase itself. If an attacker can recreate generated credentials locally, they may then try only the most promising result against the real service.
Use layered protection
Enable multi-factor authentication, passkeys, login alerts, and recovery codes whenever a service supports them. A generated password should be one layer rather than the entire security plan. For highly sensitive accounts, consider a mature password manager or hardware-backed passkey solution with documented recovery.
Related guidance
See how to create a strong passphrase and read how Kardix derives separate outputs.