pilcrowonpaper
commented
7 months ago I've added more nuance to the "Error handling" section in the password authentication page (might be worth changing the section name). The current recommendation is to pretty much ignore the issue unless you strictly need to keep the identifier private.
https://thecopenhagenbook.com/password-authentication#error-handling
In various journeys of an applications functions it's possible to infer the presence of a identity such as
New user sign up is provided an email that is checked 'that account already exists' <-- this is a point of enumeration Forgotten Password is often a point of enumeration too altho often a little noisier <-- user doesn't exist versus email sent Login page also a point of enumeration <-- user does not exist versus incorrect password
Areas like these should either send to the user's provided email address actions to authenticated such as how Spotify's magic link works or send an email suggesting someone has attempted to sign up using this email address if the account doesn't exist yet
where an application cannot do this, it must be aware of the enumeration and scraping potential
Does this make sense ?
I can put something in long form if needed, but in principle, how are re defending from scraping and inference based learning for unauthenticated visitors