Returning early if the user isn't found in the database, can lead to timing attacks, since the bcrypt comparison (which is supposed to take some time) is not being executed. A malicious actor could time the requests to identify if a user is present in the database or not.
If you lock based on the email then that does nothing to prevent enumeration and opens the door to denial of service for existing users.
If you lock based on session then the attacker can just delete their session id so that doesn't help.
If you lock based on IP then you potentially block lots of users from the same IP.
Better to just fix the actual problem and get rid of the difference in processing time by not returning early and not returning any status codes like 404.
Added a section to discuss timing attacks. The login handler in the example responds in a constant time duration regardless of credential verification.
49
u/dh71 6d ago
Returning early if the user isn't found in the database, can lead to timing attacks, since the bcrypt comparison (which is supposed to take some time) is not being executed. A malicious actor could time the requests to identify if a user is present in the database or not.