Common mistakes are treating SHA as encryption, using it without a secret for password storage, and assuming any SHA output proves integrity or authenticity. SHA only produces a digest. For passwords, use a dedicated password hashing function with a salt and work factor. For integrity, pair hashing with a trusted signing or MAC process.
What SHA does and does not do
SHA is a cryptographic hash function, so its job is to compress input into a fixed-length digest. The mistake is to treat that digest like ciphertext, access control, or proof by itself. A hash can help detect accidental change, but it does not hide data, prove who created it, or establish trust on its own.
That distinction matters because SHA is often used in places where people expect more than it can provide. If you need confidentiality, use encryption. If you need authenticity or origin assurance, use a signing or MAC process. If you need password storage, use a purpose-built password hashing scheme instead of a general hash.
Common SHA misuse patterns in real systems
One common error is using SHA directly for password storage. Fast hashes are intentionally easy to compute, which makes them a poor choice against offline guessing. Another error is relying on a bare hash as an integrity check without a trusted key or signature, which leaves the check vulnerable to replacement by an attacker who can modify both the data and the digest.
A third mistake is assuming all SHA uses are interchangeable. Digest format, truncation, collision resistance, and context all matter. SHA can be part of a sound design, but only when the surrounding construction matches the security goal. For example, keyed authenticity and unkeyed integrity are not the same property, and password verification is not the same as file verification.
For practitioners who want the underlying cryptographic basics refreshed, the Cryptography Basics Guide is the most relevant NHIMG starting point because it covers hashes, HMAC, signatures, and the boundaries between them.
How to choose the right construction instead of raw SHA
If the goal is password storage, use a dedicated password hashing function with a salt and work factor. If the goal is integrity over data in transit or at rest, pair the hash with a signature or MAC so the digest cannot simply be recomputed by an attacker. If the goal is software or artifact verification, make sure the trust anchor is external to the object being checked.
For teams that repeatedly trip over weak secret handling, the Top 10 Secrets Management Mistakes guide helps with the adjacent problem of long-lived secrets, while Top 10 MFA Mistakes is useful where authentication mistakes are being confused with hashing mistakes. SHA can support the design, but it should not be used as a substitute for the control that actually provides the security property you need.
Risk and Threat Considerations
SHA misuse becomes risky when teams infer more from a digest than the algorithm can actually provide. The practical failure modes are password cracking, tampered integrity checks, and false confidence in authenticity, especially when the hash is stored or transmitted alongside the protected object.
Failure mechanism: An attacker who can alter content can often also replace an unkeyed digest, and a fast general-purpose hash gives little resistance to offline password guessing.
Impact: Systems may accept altered data, expose reusable passwords to rapid brute force, or treat unauthenticated content as trusted when it is not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | SHA misuse often appears in data-at-rest protection decisions and integrity design. |
| IA-5 — Authenticator Management | Password hashing mistakes directly affect credential storage and verifier design. | |
| Recommendation — Use keyed integrity or encryption controls where a bare hash cannot provide the required protection. Store passwords with purpose-built verifiers, salts, and work factors rather than raw SHA. | ||
| OWASP ASVS | V11 — Cryptography | SHA questions center on correct hash, MAC, and signature use in application security. |
| Recommendation — Verify that hashing is used only for the property it actually provides and pair it with authentication or integrity controls when needed. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Using hashes correctly is part of protecting sensitive data and avoiding false integrity assumptions. |
| Recommendation — Apply stronger protections than raw hashing when data confidentiality, integrity, or password safety is required. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | SHA is a cryptographic primitive whose safe use depends on correct cryptographic application. |
| Recommendation — Define when hashing, MACs, or signatures are appropriate and prohibit bare hashes from standing in for trust. | ||
Practitioner Guidance
What to verify: Check whether SHA is being used for the right job, not just whether it is being used. If the requirement is confidentiality, authenticity, or password defense, SHA alone is the wrong mechanism.
Decision rule: If a digest is meant to prove trust, ask what prevents an attacker from recomputing it. If nothing prevents that, the design needs a keyed or signature-based control instead of a bare hash.
Common mistake: Teams often keep legacy SHA usage because it "works" in testing. The real test is whether the construction still holds when an attacker can read, copy, and modify both the data and its digest.
Practitioner takeaway: SHA is a primitive, not a complete security control. Use it only where an unkeyed digest is sufficient, and add salt, work factors, keys, or signatures when the security goal demands more.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org