# Hash Preimage Finder > Watch a bounded, local brute-force search recover a weak hash input in seconds, or run out of keyspace on anything with real entropy. No wordlist, no table, just your browser. A demonstration of why fast, unsalted hashes fail. - Tool: https://ronutz.com/en/tools/hash-preimage-finder - Family: Hashing & crypto --- ## What it does This is a teaching tool. It runs a bounded, brute-force search in your browser that tries to find an input whose hash matches a target digest. Against a weak input, a short PIN or a few lowercase letters, it succeeds in seconds; against anything with real entropy it exhausts its capped keyspace and stops without an answer. That contrast is the point: it shows, first-hand, why a fast unsalted hash is a poor way to protect a password, and why a high-entropy secret is safe even against direct search. ## What a preimage is, and how the search works A hash is one-way, so there is no formula that turns a digest back into its input. The only generic way to reverse one is to guess: pick a candidate, hash it, and see whether the digest matches. This finder does exactly that. It enumerates candidates over an alphabet and length you choose (digits, lowercase letters, and so on) and hashes each one locally until it finds a match or runs out of candidates. It uses no dictionary, no wordlist, and no precomputed table, so it is purely a demonstration of exhaustive search, not a password-cracking kit. ## Why weak inputs fall and strong ones do not The number of candidates is the size of the alphabet raised to the length. A 4-digit PIN is only 10^4, that is 10,000 possibilities, trivially searchable; six lowercase letters is 26^6, about 300 million, still small for a computer; but every extra character multiplies the space, so a genuinely random secret pushes the count far beyond what any bounded local search can cover. This is exactly why fast hashes like MD5 or SHA-256, which can be computed billions of times per second, are unsuitable for passwords, and why real systems add a salt and use a deliberately slow key-derivation function, as recommended by the OWASP Password Storage guidance and NIST SP 800-63B. ## What it cannot do Because the keyspace is capped and there is no wordlist, the tool only ever recovers inputs that were already known to be weak. It cannot attack a salted hash, and it cannot attack a hash produced by a slow key-derivation function such as bcrypt, scrypt, Argon2, or PBKDF2, which are designed to make each guess expensive. ## Using it Enter a target digest, or hash a sample input to produce one, choose the alphabet and maximum length to search, and watch the search run. Try a short numeric input to see it succeed quickly, then add length or widen the alphabet to watch the keyspace outrun the search. ## Standards and references - [RFC 1321 - The MD5 Message-Digest Algorithm](https://www.rfc-editor.org/rfc/rfc1321) - [RFC 3174 - US Secure Hash Algorithm 1 (SHA1)](https://www.rfc-editor.org/rfc/rfc3174) - [FIPS 180-4 - Secure Hash Standard (SHA-256)](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) - [OWASP - Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) - [NIST SP 800-63B - Digital Identity Guidelines (Authentication)](https://pages.nist.gov/800-63-3/sp800-63b.html) ## Related reading - [Brute Force vs Lookup Tables: Two Ways to Reverse a Hash](https://ronutz.com/en/learn/brute-force-vs-lookup-tables.md): Since a hash cannot be inverted, reversing one means searching, and there are two families. Precompute a giant table of input-to-hash pairs and look the hash up (what CrackStation does), or generate candidates on the fly and hash each until one matches (brute force). They trade storage for compute in opposite directions. - [Choosing a Password Hash](https://ronutz.com/en/learn/choosing-a-password-hash.md): Storing passwords safely is a solved problem: use a purpose-built, salted, slow password hash, not a raw digest. This is a short decision guide, from the algorithm to pick to the parameters to set and the mistakes to avoid, aligned with OWASP and NIST guidance. - [Keyspace, Entropy, and Crack Time](https://ronutz.com/en/learn/keyspace-entropy-and-crack-time.md): Whether brute force can reverse a hash comes down to keyspace size versus the attacker's hashing rate. Keyspace grows exponentially with length and alphabet, so a few extra characters move a secret from cracked in seconds to infeasible for millennia. This is the arithmetic behind why length and randomness matter most. - [Slow KDFs: bcrypt, scrypt, and Argon2](https://ronutz.com/en/learn/slow-kdfs-bcrypt-scrypt-argon2.md): Salting defeats precomputation but not a targeted guess-and-check attack; a fast hash still lets an attacker try billions of candidates per second. Slow key derivation functions fix that by making each guess deliberately expensive and tunable, cutting an attacker's rate by many orders of magnitude. These are what you should store passwords with. - [Why Cryptographic Hashes Are One-Way](https://ronutz.com/en/learn/why-hashes-are-one-way.md): A cryptographic hash maps any input to a fixed-size digest and is designed so that recovering the input from the digest is infeasible. That property, preimage resistance, is why you cannot decrypt a hash. The only ways to reverse one are to look it up or to guess-and-check, both of which are search, not inversion. - [Why Salting Defeats Precomputed Tables](https://ronutz.com/en/learn/why-salting-defeats-precomputed-tables.md): A salt is a unique random value stored with each password hash and mixed in before hashing. It makes identical passwords hash differently, which destroys the economics of precomputed tables: an attacker would need a separate table for every salt. Salting is the specific defense that neutralizes lookup services and rainbow tables.