8

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?

Improve this question
3
  • 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
    Commented May 19, 2015 at 18:16
  • Their username is their email address.
    – Dev Chakraborty
    Commented May 19, 2015 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Ζ
    Commented May 19, 2015 at 18:21

3 Answers 3

Reset to default
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.
Improve this answer
1
  • 1
    Good suggestions. I ended up having the invalid response also do the bcrypt calculations.
    – Dev Chakraborty
    Commented May 21, 2015 at 17:50
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.

Improve this answer
-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.

Improve this answer
4
  • 2
    If the login is an email address, it is a privacy leak to reveal this. Consider the implication if someone could tell that [email protected] had an account on footfettish.com?
    – paj28
    Commented May 19, 2015 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
    Commented May 19, 2015 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
    Commented May 19, 2015 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, but I wouldn't say it's 'correct' way, just because it's less user-friendly and makes almost no sense IMHO
    – Timofey
    Commented May 19, 2015 at 18:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .