For the server, maybe. For the user, a password manager (used properly) is a solid single defense solution.
I checked the list of passwords, and a significant amount had values like "uRFcWEBSITENAME".
I reasoned first they would try USERNAME, PASSWORD, and then try USERNAME with passwords updated for the other websites they were hacking.
Even the section of passwords beginning with just the first letter of WEBSITENAME was unusually large. Then I scanned for passwords containing the first few letters of WEBSITENAME... yup, a conspicuous lot of them. Those people at least tried to be smart about their password uniqueness, but it didn't really work.
If so, why does that provide protection against credential stuffing? A username can be reused across different applications.
What am I missing?
No, he means a unique user id, generated by the server when you sign up for the service. Then for every login attempt, you provide the username/email + user id + password.
Would love to hear from other folks who have implemented this on how it affects the user experience. Seems to me it'd be high friction.
Also, wouldn't this prevent lost password recovery? if you can't identify a user by their email?
You'd presumably do username recovery the same way you do password recovery, so it would only be accessible to an attacker who compromised the user's email.
The commenter already acknowledged that the solution has drawbacks. The only claim made was that it solves credential stuffing, not that it doesn't inconvenience the user.
> This would only work for those with a password manager
It would also work for those without a password manager, because they'd have no choice.
> Also, wouldn't this prevent lost password recovery? if you can't identify a user by their email?
They're not mutually exclusive. You can have both. A compulsory unique user ID to login, and an email based password recovery mechanism.