| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The affected Bachmann Electronic M-Base Controllers of version MSYS v1.06.14 and later use weak cryptography to protect device passwords. Affected controllers that are actively supported include MX207, MX213, MX220, MC206, MC212, MC220, and MH230 hardware controllers, and affected end-of-life controller include MC205, MC210, MH212, ME203, CS200, MP213, MP226, MPC240, MPC265, MPC270, MPC293, MPE270, and CPC210 hardware controllers. Security Level 0 is set at default from the manufacturer, which could allow an unauthenticated remote attacker to gain access to the password hashes. Security Level 4 is susceptible if an authenticated remote attacker or an unauthenticated person with physical access to the device reads and decrypts the password to conduct further attacks. |
| The affected Baker Hughes Bentley Nevada products (3500 System 1 6.x, Part No. 3060/00 versions 6.98 and prior, 3500 System 1, Part No. 3071/xx & 3072/xx versions 21.1 HF1 and prior, 3500 Rack Configuration, Part No. 129133-01 versions 6.4 and prior, and 3500/22M Firmware, Part No. 288055-01 versions 5.05 and prior) utilize a weak encryption algorithm for storage and transmission of sensitive data, which may allow an attacker to more easily obtain credentials used for access. |
| In Yeastar N412 and N824 Configuration Panel 42.x and 45.x, an unauthenticated attacker can create backup file and download it, revealing admin hash, allowing, once cracked, to login inside the Configuration Panel, otherwise, replacing the hash in the archive and restoring it on the device which will change admin password granting access to the device. |
| AMI Megarac Weak password hashes for
Redfish & API |
| Phpgurukul Online Birth Certificate System 1.0 suffers from insufficient password requirements which can lead to unauthorized access to user accounts. |
| Weak password hashing using MD5 in funzioni.php in HotelDruid before 1.32 allows an attacker to obtain plaintext passwords from hash values. |
| IBM Security Verify Governance 10.0.2 Identity Manager
uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input. |
| CodeIgniter Shield provides authentication and authorization for the CodeIgniter 4 PHP framework. An improper implementation was found in the password storage process. All hashed passwords stored in Shield v1.0.0-beta.3 or earlier are easier to crack than expected due to the vulnerability. Therefore, they should be removed as soon as possible. If an attacker gets (1) the user's hashed password by Shield, and (2) the hashed password (SHA-384 hash without salt) from somewhere, the attacker may easily crack the user's password. Upgrade to Shield v1.0.0-beta.4 or later to fix this issue. After upgrading, all users’ hashed passwords should be updated (saved to the database). There are no known workarounds. |
| 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. |
| XWiki Platform is a generic wiki platform. Starting in version 5.0-rc-1 and prior to versions 14.10.19, 15.5.4, and 15.9-rc-1, it is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it's possible for an attacker to have access to the hash password of a user if they have rights to edit the users' page. With the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages. There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has been deleted should be considered at risk and the password should be changed there. a diff, to ensure it's not coming from a password field. As another mitigation, admins should ensure that the user pages are properly protected: the edit right shouldn't be allowed for other users than Admin and owner of the profile (which is the default right). There is not much workaround possible for a privileged user other than upgrading XWiki. |
| RedTeam Pentesting discovered that the web interface of STARFACE as well as its REST API allows authentication using the SHA512 hash of the password instead of the cleartext password. While storing password hashes instead of cleartext passwords in an application's database generally has become best practice to protect users' passwords in case of a database compromise, this is rendered ineffective when allowing to authenticate using the password hash. |
| The default password hashing algorithm (PBKDF2-HMAC-SHA1) in Liferay Portal 7.2.0 through 7.4.3.15, and older unsupported versions, and Liferay DXP 7.4 before update 16, 7.3 before update 4, 7.2 before fix pack 17, and older unsupported versions defaults to a low work factor, which allows attackers to quickly crack password hashes. |
| The LMS5xx uses weak hash generation methods, resulting in the creation of insecure hashs. If an attacker manages to retrieve the hash, it could lead to collision attacks and the potential retrieval of the password. |
|
Franklin Fueling System TS-550 versions prior to 1.9.23.8960 are vulnerable to attackers decoding admin credentials, resulting in unauthenticated access to the device.
|
| CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES 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 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations. |
| Buttercup v2.20.3 allows attackers to obtain the hash of the master password for the password manager via accessing the file /vaults.json/ |
|
PiiGAB M-Bus stores passwords using a weak hash algorithm.
|
| Vulnerability in ekorCCP and ekorRCI that could allow an attacker with access to the network where the device is located to decrypt the credentials of privileged users, and subsequently gain access to the system to perform malicious actions. |
| Inoda OnTrack v3.4 employs a weak password policy which allows attackers to potentially gain unauthorized access to the application via brute-force attacks. Additionally, user passwords are hashed without a salt or pepper making it much easier for tools like hashcat to crack the hashes. |
| Bminusl IHateToBudget v1.5.7 employs a weak password policy which allows attackers to potentially gain unauthorized access to the application via brute-force attacks. Additionally, user passwords are hashed without a salt or pepper making it much easier for tools like hashcat to crack the hashes. |
