Implement the https://haveibeenpwned.com/ API, to verify that passwords do not exist in known password dumps from security breaches. This can be done easily with Symfony's NotCompromisedPassword constraint. Disabled by default, for BC and for not doing requests to this external API without the knowledge of the site owners.

PRs:
https://github.com/ibexa/core/pull/221
https://github.com/ibexa/admin-ui/pull/750
Doc: https://github.com/ezsystems/developer-documentation/pull/1967

QA, testing
Edit the User CT, the user account FT should have a new "Password must not be contained in a public breach" setting. If you enable this, and disable all other password constraints, then when you change your password you should get a failure for "secret", for instance. While "p98w57fp9j8w75p89p98fljfs9d8j73" should probably pass. It also works with other contraints active, of course.

Documentation
The password rules page needs documentation for this feature. See the two attached screenshots. You might also want to mention the NotCompromisedPassword Symfony doc and/or the k-Anonymity explanation it links to, which shows how the API can validate the password without sending the password to the API. This could be important for some administrators who may be scared by the feature. Ping gunnstein.lye@ibexa.co if anything is unclear.

Limitations
Since this is done in the password validator, and passwords are only validated when created or changed, there is no warning message when already existing bad passwords are used to log in. That could also be useful, but it means a whole lot more requests to this API, most of which would be pointless repetitions. We could limit it to only one check per password hash, and unset that bit when the hash changes. But if the check is enabled, further login checks are again pointless, so we'd need to take that into account too, and it gets complicated. Might be better to just add an extra button to the login form: "Check if my password has been exposed". Then the users have the choice. But let's do that in a separate PR, if at all.

Our permission to use the API
AFAICT, while you need to buy an API key to use the email/username based haveibeenpwned search, there is no such requirement for the password based search. There is also no rate limiting or attribution requirement, as they say: "In order to help maximise adoption, there is no licencing or attribution requirements on the Pwned Passwords API, although it is welcomed if you would like to include it." https://haveibeenpwned.com/API/v3
It would be nice of us to attribute them anyway, and donate/sponsor, of course.