News for hackers. Stuff that matters.
Re:Credential Stuffing by rokkamokka on Thursday October 16, 2025 @08:42AM (#45604634)
I'd argue that the really old custom of providing the user a fixed username (e.g. user ID) upon registration, and requiring that for login, provides complete protection vs credential stuffing. It has other drawbacks of course, which is why you rarely see it in use anymore...
Re:Credential Stuffing by mooreds on Thursday October 16, 2025 @08:59AM (#45604781)
Do you mean a username that is distinct from email or phone number?

If so, why does that provide protection against credential stuffing? A username can be reused across different applications.

What am I missing?

Re:Credential Stuffing by jaratec on Thursday October 16, 2025 @09:15AM (#45604945)
> Do you mean a username that is distinct from email or phone number?

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.

Re:Credential Stuffing by mooreds on Friday October 17, 2025 @06:28AM (#45615058)
Thanks.

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.

Re:Credential Stuffing by IAmBroom on Thursday October 16, 2025 @09:11AM (#45604906)
How does providing a predictable username protect against anything at all?
Re:Credential Stuffing by aetherson on Thursday October 16, 2025 @09:17AM (#45604980)
Because credential stuffing relies on the user reusing a username + password from another site. If you provide the user with a username they don't select, it won't be reused.
Re:Credential Stuffing by gregoriol on Thursday October 16, 2025 @09:29AM (#45605115)
But then they have to remember the username AND the password? This doesn't help with users already having the password re-use problem. This would only work for those with a password manager, but then they are also less likely to re-use a password.

Also, wouldn't this prevent lost password recovery? if you can't identify a user by their email?

Re:Credential Stuffing by aetherson on Thursday October 16, 2025 @12:06PM (#45607124)
Yes, there are clear ergonomic reasons why we don't do this "assign a username" thing. But it would stop password stuffing.

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.

Re:Credential Stuffing by jbstack on Thursday October 16, 2025 @09:43AM (#45605256)
> But then they have to remember the username AND the password?

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.

Re:Credential Stuffing by anonymousiam on Friday October 17, 2025 @02:02AM (#45613711)
I haven't used it for 45 years, but my CompuServe user ID was [72175,1425]. I like that they assigned it themselves with no input from me. (I'm cursed with a good memory for useless things.)

https://en.wikipedia.org/wiki/CompuServe