crypto-js is a JavaScript library of crypto standards. Prior to version 4.2.0, crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 4.2.0 contains a patch for this issue. As a workaround, configure crypto-js to use SHA256 with at least 250,000 iterations.

Affected: npm: crypto-js

### Impact #### Summary Crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and [at least 1,300,000 times weaker than current industry standard][OWASP PBKDF2 Cheatsheet]. This is because it both (1) defaults to [SHA1][SHA1 wiki], a cryptographic hash algorithm considered insecure [since at least 2005][Cryptanalysis of SHA-1] and (2) defaults to [one single iteration][one iteration src], a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to [preimage][preimage attack] and [collision][collision attack] attacks.

Potential Impact:

1. If used to protect passwords, the impact is high. 2. If used to generate signatures, the impact is high.

Probability / risk analysis / attack enumeration:

1. [For at most $45,000][SHA1 is a Shambles], an attacker, given control of only the beginning of a crypto-js PBKDF2 input, can create a value which has _identical cryptographic signature_ to any chosen known value. 4. Due to the [length extension attack] on SHA1, we can create a value that has identical signature to any _unknown_ value, provided it is prefixed by a known value. It does not matter if PBKDF2 applies '[salt][cryptographic salt]' or '[pepper][cryptographic pepper]' or any other secret unknown to the attacker. It will still create an identical signature.

Update: PBKDF2 requires a pseudo-random function that takes two inputs, so HMAC-SHA1 is used rather than plain SHA1. HMAC is no…

crypto-js: PBKDF2 1,000 times weaker than specified in 1993 and 1.3M times weaker than current standard dotnet: Information Disclosure: MD.SqlClient(MDS) & System.data.SQLClient (SDS) dotnet: X509 Certificates - Validation Bypass across Azure dotnet: .NET Denial of Service Vulnerability

Affected: Ubuntu:Pro:16.04:LTS: cryptojs, Ubuntu:Pro:18.04:LTS: cryptojs, Ubuntu:20.04:LTS: cryptojs, Ubuntu:Pro:22.04:LTS: cryptojs, Ubuntu:24.04:LTS: cryptojs

crypto-js is a JavaScript library of crypto standards. Prior to version 4.2.0, crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 4.2.0 contains a patch for this issue. As a workaround, configure crypto-js to use SHA256 with at least 250,000 iterations.

Ein Angreifer kann mehrere Schwachstellen in IBM Security Verify Access ausnutzen, um Administratorrechte zu erlangen, beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, Cross-Site-Scripting-Angriffe durchzuführen sowie Daten zu verändern oder offenzulegen.