“Store SHA-256 instead of the plain password” sounds safer, but it is still not an adequate password-storage design. Before choosing an algorithm, separate three different jobs: file integrity, keyed message authentication, and password verification.
File digests: use SHA-256 or SHA-512
A digest helps determine whether content has changed. For example, a publisher can provide an installer and its SHA-256 value, allowing recipients to calculate and compare the result. The Hash Calculator supports MD5, SHA-1, SHA-256, SHA-384, and SHA-512 and performs the calculation locally in the browser.
MD5 and SHA-1 are no longer appropriate when malicious collisions matter. They may still appear in legacy compatibility or non-security checks, but new systems should prefer SHA-256 or a stronger algorithm.
A digest only establishes that the input is the same. It does not establish who created the digest. If an attacker can replace both a file and its published checksum, an ordinary hash cannot detect the substitution.
Message authentication: use HMAC
HMAC combines a shared secret with a hash function to authenticate message integrity and origin. Common uses include webhook signatures and service-to-service request signing. The HMAC Calculator supports SHA-1, SHA-256, SHA-384, and SHA-512.
Real integrations must also define byte encoding, canonical message construction, output encoding, and constant-time comparison. Do not paste production secrets into an uncontrolled environment; use temporary keys when debugging examples.
Password storage: use a dedicated slow algorithm
General-purpose SHA functions are intentionally fast. That is useful for file digests and harmful for password storage because an attacker can test large numbers of candidates quickly. Production systems should use a password-hashing algorithm:
- Prefer Argon2id, with memory, iteration, and parallelism settings appropriate for the server.
- Use scrypt when Argon2id is unavailable.
- Use bcrypt with a suitable cost when framework compatibility is important.
These operations belong in a mature backend library and should use a unique random salt for every password. DevToolbox does not currently provide Argon2, scrypt, or bcrypt, so the Hash Calculator must not be used to generate database password fields.
What does the Password Checker actually check?
The Password Checker runs a local set of heuristics for length, uppercase and lowercase characters, digits, special characters, common weak-password fragments, repeated characters, and whether the value contains a supplied username or email fragment.
It does not query a breached-password database and cannot estimate the real cracking cost for a particular attacker. Passing every rule only means that none of the current checks fired. It is not a security guarantee. Prefer a password manager that generates a unique long password, and enable multi-factor authentication where available.
Practical selection table
| Requirement | Recommended | Do not use |
|---|---|---|
| File or text digest | SHA-256 / SHA-512 | MD5 for security-sensitive verification |
| Keyed request signature | HMAC-SHA-256 or similar | Hashing a concatenated secret and message |
| Database password storage | Argon2id / scrypt / bcrypt | MD5, SHA-1, or one round of SHA-256 |
| Personal password generation | A password manager or Password Generator | Reusing one password across services |
The algorithm name is only part of the design. Parameter selection, secret management, rate limiting, multi-factor authentication, and migration plans matter as well.