7

I have a site on which I would like to prevent an unauthenticated attacker from knowing if an account exists. On the site, passwords are hashed using bcrypt, so login requests must do a bcrypt comparison (strength 12) – which takes CPU time.

My concern: the server response time varies depending on whether the user account was found or not. If the account was found, the bcrypt comparison runs to check the password; if not, the function can return immediately. On my local machine, I'm getting ~600ms response time when the account is found, while I'm getting ~30ms response time when it is not. In production, just add network latency to both.

In short, as a client, I could determine whether an account exists.

My question: Is this something I should be concerned about? And if so, what's the best solution – an artificial wait? A lower bcrypt strength? A faster hashing algorithm?

Community
  • 1
Dev Chakraborty
  • 73
  • 5
  • 3
    Is the user name something a user picks when they register? If so, you can't avoid the registration process having this leak, so I wouldn't worry. If their user name is their email address then I would worry - you need to bcrypt (or sleep for an equivalent time) when the user doesn't exist. – paj28 May 19 '15 at 18:16
  • Their username is their email address. – Dev Chakraborty May 19 '15 at 18:21
  • 1
    I second @paj28's motion to bcrypt no matter what. Gives consistent timings and should be well within the performance of the server. – RoraΖ May 19 '15 at 18:21

3 Answers3

5

Yes you should be concerned about this. Its a possible side-channel and it reveals information about your system. Some possible defenses (that are being used) are:

  • Use a pseudo random minimum wait delay. (this means that a valid or invalid response will take about the same amount of time)
  • have an invalid response do all the calculation steps of a valid response (just with a invalid as return value). this is CPU intensive but often employed through ignorance. (the engineers just make everything go through all the steps)
  • Incremental Delay (each attempt doubles a delay factor) the iphone employes this for example.
  • Use a central authentication service that employs some defense against this. either through traffic or some other means.
LvB
  • 8,217
  • 1
  • 26
  • 43
1

I think that Linux uses some increasing delay for invalid logins. For example, if you login with a bad username or password, there's something like a 1 second delay on your first attempt, 2 seconds on your next attempt, 4 on your third, etc... This both hides the calculation delay that you are concerned with as well as slowing down people trying to mine your authentication process for data.

Combining this delay with calling bcrypt even for an incorrect username should provide you a fair amount of protection against timing attacks.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
-2

Usually it's not a problem that an attacker knows if login exists or not, so if you don't know if it's important for you then most likely it's not. But if you still want to hide the fact login is not exists then I would suggest to add some delay. Probably the best way will be to actually check some hash (and finally return 'false' anyway) so waiting time will be actually dependend on webserver CPU load, bcrypt strength etc.

Timofey
  • 1
  • 2
    If the login is an email address, it is a privacy leak to reveal this. Consider the implication if someone could tell that timofey.sorokin@myjob.com had an account on footfettish.com? – paj28 May 19 '15 at 18:23
  • @paj28, I agree that it might be an issue, but you also mentioned that if you have open registration then you'll have a chance to check an email anyway. So response time doesn't matter, an attacker will just check registration form validation messages. – Timofey May 19 '15 at 18:29
  • If you code your registration form correctly you can avoid the leak there. There's advice online how to do this. – paj28 May 19 '15 at 18:38
  • @paj28, yes, you're right, there IS actually a way to implement registration form (and all similar functionality like 'forgot password') a way to [avoid information leak](http://security.stackexchange.com/questions/40694/disclose-to-user-if-account-exists), but I wouldn't say it's 'correct' way, just because it's less user-friendly and makes almost no sense IMHO – Timofey May 19 '15 at 18:59