[KolmogorovComp]

> ... and then realize with a horrible feeling that some % of those hits are getting through the login page.

(Non sarcastic), why would you feel bad for users using 1234 as their passwords? Unless your website is aimed at vulnerable people, I consider this to be their responsibility.

As other comments have said these users will probably go the easiest route (1234websitename) to fix the error.

Any restriction you put on your password field reduces entropy, and safety for everyone (even if marginally so).

[cqqxo4zV46cp]

Because anyone that has ever been responsible for anything knows that there’s a difference between something being your fault and something being your problem.

Breach notification etc legislation in some jurisdictions will also require that you report successful widespread credential stuffing.

Even AWS with their “shared responsibility model” works with GitHub etc to ensure that programmatic access credentials aren’t accidentally exposed via public repositories. This isn’t credential stuffing, but it’s a blindingly accurate demonstration of the fact that drawing a line in the sand and saying “users, work it out from here!” and attempting to wash your hands of the situation is nothing more than the ill-informed pipe dream of someone that’s never had to deal with this stuff in reality.

[CoffeeOnWrite]

Have you ever operated an online business? Poor password choice is practically harmful to business. Marginal reduction of entropy by blocking breached passwords, what's the practical harm from that?

1234websitename is objectively better than 1234.

I'll go with NIST on this one (yes, and have a minimum length too):

> When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised... If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret