0

Consider the case of username enumeration, where a hacker is able to determine a username based on UI feedback being different from a successful entry vs a failed entry.

For example, a website's forgot password page asks for a username. If upon clicking submit with a username, the UI displays that the username is not found or is found, this is a classic case of username enumeration because it can be exploited easily by looking through all cases where username is found and not found

But, what if other inputs are required on the screen. For example, the forgot password page now requires you to enter username + last 4 ssn + zip code. When a user enters values for all 3 inputs, but don't exactly match, the UI would display "match not found". Additionally, after X number of attempts with a valid username but incorrect zip code or ssn, the account is locked (UI would not say account is locked, but email is triggered). Would you consider this to still have a username enumeration issue?

AgentOrange90
  • 1
  • 2
  • **Why or why not?** is not much appreciated in this community – elsadek Mar 30 '20 at 21:18
  • Do these additional inputs make enumeration harder? Sure. But do they actually prevent the enumeration? Depends on how complex and unguessable they are. If too easy the enumeration will just be harder but not impossible. – Steffen Ullrich Mar 30 '20 at 21:46
  • This would create a new problem, which might be worse than username enumeration: if you know a person's username and zip code, you can take guesses at the last four digits of their SSN until you hit the account lockout. – Josh Townzen Mar 30 '20 at 22:23
  • Locking out _potential_ matches from an unauthenticated request isn't something we've seen in the wild. Username enumeration has simple and effective countermeasures such as a generic error response and others. – identigral Mar 31 '20 at 03:58
  • Does this answer your question? [User name enumeration?](https://security.stackexchange.com/questions/42872/user-name-enumeration) – LvB Mar 31 '20 at 12:09
  • @LvB not really. Basically, I am replacing the password with last 4 of ssn + zip code. The UI will still display a generic message much like when an incorrect username + password is entered. I should mention that this is only the first gate of the forgot password workflow, with the second being an OTP sent via email or sms – AgentOrange90 Mar 31 '20 at 13:50
  • in essence if you have a differential feedback based on whether the entry is known or unknown its open to harvesting. – LvB Mar 31 '20 at 13:51
  • @LvB agreed, but can't the same be said about username + password entry? the proposal would be if one of the username + last 4 ssn + zip code didn't match the profile, the UI would display "no match" message. the no match message is generic in that the attack doesn't know which of the 3 inputs is correct, incorrect, or not the actual match – AgentOrange90 Mar 31 '20 at 14:05
  • there should only be 2 possible repsonses: No entry (in human friendly way but non specific) and Entry (you have succesfully authenticated). anthing else is vulnerable to harvesting in some way. – LvB Mar 31 '20 at 14:08

0 Answers0