Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Compromised Passwords Could be Used
The application does not check passwords against a set of breached passwords that match the system’s password policy.
If an application fails to validate passwords against a set of breached passwords aligned with the system's password policy, it poses potential impacts:
• Credential Stuffing Attacks: Attackers can leverage breached password databases to launch credential stuffing attacks, trying known compromised passwords across various accounts, leading to unauthorized access.
• Data Breach Risk: Failure to identify breached passwords increases the likelihood of successful brute-force attacks, potentially resulting in a data breach with sensitive user information exposed.
Remediation
The application should block common and compromised passwords. For this purpose, it can use the Pwned Passwords service. It can host it or use its API:
• https://haveibeenpwned.com/Passwords
• https://haveibeenpwned.com/API/v3#PwnedPasswords
See ASVS v4.0.3, section 2.1.7:
Verify that passwords submitted
during account registration, login, and password change are checked
against a set of breached passwords either locally (such as the top
1,000 or 10,000 most common passwords which match the system's
password policy) or using an external API. If using an API a zero
knowledge proof or other mechanism should be used to ensure that the
plain text password is not sent or used in verifying the breach status
of the password. If the password is breached, the application must
require the user to set a new non-breached password.
Hi Václav,
The https://liferay.atlassian.net/browse/LPS-121598 feature request covers this one also.
Regards,
Zsigmond
Thank you, Zsigmond.
Powered by Liferay™