Rule Information
Tags
pythonsha1weak-hashcryptographyhashlibCWE-327OWASP-A02
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-LANG-SEC-031 --project .1
2
3
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
About This Rule
Understanding the vulnerability and how it is detected
SHA-1 (Secure Hash Algorithm 1) produces a 160-bit digest and has been deprecated for cryptographic use since 2011. In 2017, the SHAttered attack demonstrated a practical SHA-1 collision, and chosen-prefix collision attacks became feasible in 2019, enabling forgery of X.509 certificates, PGP keys, and other structures that use SHA-1 signatures.
SHA-1 should not be used for digital signatures, certificate fingerprinting, HMAC in new protocols, code signing, password hashing, or any context where collision resistance is a security requirement. NIST formally deprecated SHA-1 for all security applications in 2022.
SHA-1 retains some non-security uses: it remains acceptable for non-adversarial integrity checks, content-addressed storage where the threat model does not include adversarial input, and HMAC-SHA1 in legacy protocol compatibility (where cryptographic analysis shows HMAC construction still provides MAC security despite the hash's weaknesses).
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Chosen-Prefix Collision Attacks
Chosen-prefix collisions allow an attacker to craft two documents with identical SHA-1 hashes where each document starts with attacker-chosen content. This has been used to forge X.509 certificates and create malicious files that match expected checksums. The attack cost is within reach of well-funded attackers.
2
Certificate Forgery
X.509 certificates using SHA-1 signatures can be forged through collision attacks. Major browser vendors and CA/Browser Forum deprecated SHA-1 certificates in 2016-2017. Applications still accepting SHA-1 certificate fingerprints are vulnerable to certificate impersonation attacks.
3
Code Signing Weakness
Software signed with SHA-1 can potentially be replaced by malicious code with a crafted collision that produces the same SHA-1 hash, undermining software supply chain integrity.
4
PGP Key Forgery
PGP/GPG uses SHA-1 for key fingerprints in older key formats. SHA-1 collision attacks have been demonstrated against PGP key certification signatures, enabling key impersonation in some configurations.
How to Fix
Recommended remediation steps
- 1Replace hashlib.sha1() with hashlib.sha256() or hashlib.sha3_256() for all security-sensitive hashing operations.
- 2Update certificate fingerprint verification to use SHA-256 fingerprints.
- 3Migrate code signing pipelines from SHA-1 to SHA-256 or stronger algorithms.
- 4For HMAC in new code, use HMAC-SHA-256; HMAC-SHA1 may be retained only for legacy protocol compatibility where migration is not feasible.
- 5Audit all SHA-1 usages and document whether each is security-sensitive or acceptable for non-adversarial use.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects calls to hashlib.sha1() in Python source code. All call sites are flagged for review. Security-sensitive uses require migration to SHA-256 or stronger. Non-security uses and HMAC-SHA1 for legacy compatibility may be documented and suppressed.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
NIST SP 800-131A Revision 2
SHA-1 is disallowed for digital signatures, key derivation, and random bit generation
OWASP Top 10
A02:2021 - Cryptographic Failures
PCI DSS v4.0
Requirement 4.2.1 - Use strong cryptography; SHA-1 not permitted for TLS
CA/Browser Forum Baseline Requirements
SHA-1 certificates deprecated since January 2017
References
External resources and documentation
Similar Rules
Explore related security rules for Python
MEDIUM
Insecure MD5 Hash Usage
MD5 is cryptographically broken and unsuitable for security-sensitive purposes. Use SHA-256 or SHA-3 instead.
MEDIUM
Insecure Hash via hashlib.new()
hashlib.new() with an insecure algorithm name (MD5, SHA1, SHA-224) creates a cryptographically weak hash. Use SHA-256 or SHA-3.
LOW
SHA-224 or SHA3-224 Weak Hash Usage
SHA-224 and SHA3-224 provide only 112-bit collision resistance, which is below the 128-bit minimum recommended by NIST for new applications.
Frequently Asked Questions
Common questions about Insecure SHA-1 Hash Usage
SHA-1 has practical collision attacks (SHAttered 2017, chosen-prefix 2019) that
are within reach of determined attackers. It is broken for collision-resistance-dependent
uses (signatures, certificates, code signing). HMAC-SHA1 retains MAC security since
HMAC's security depends on pseudorandomness rather than collision resistance, but
HMAC-SHA256 is strongly preferred for new code.
Git historically used SHA-1 for content addressing (not digital signatures), where
the threat model is accidental corruption rather than adversarial collision. Git is
transitioning to SHA-256 (SHA-256 repository support was added in Git 2.29). Legacy
protocols using HMAC-SHA1 (e.g., TOTP, some OAuth variants) retain security because
HMAC construction is not broken by SHA-1 collision attacks.
SHA-1 is stronger than MD5 (160-bit vs 128-bit digest, more complex structure) but
both have practical collision attacks and should not be used for security purposes.
SHA-1 collision attacks are more expensive than MD5 collision attacks but have been
demonstrated. The migration guidance is the same: use SHA-256 or stronger.
For new code: use SHA-256 immediately. For existing systems: prioritize certificate
fingerprints and code signing (highest risk), then integrity verification, then
content addressing. HMAC-SHA1 in legacy protocols can be lower priority if migration
cost is high, but should be documented with a migration plan.
In FIPS 140-3 mode, SHA-1 is not approved for security applications. Python's hashlib
in FIPS mode may raise an error or require the usedforsecurity=False parameter when
creating a SHA-1 hash. Systems operating under FIPS requirements must migrate away
from SHA-1 in all security-sensitive contexts.
SHA-1 is computationally heavy compared to purpose-built non-cryptographic hash
functions. For hash tables and checksums with no adversarial threat model, use
xxHash, SipHash, or Python's built-in hash() instead. SHA-1 is neither the safest
nor the most performant choice for non-security hash uses.
New feature
Get these findings posted directly on your GitHub pull requests
The Insecure SHA-1 Hash Usage rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.