5 ms·

This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error messag

• Dylan16807 12y ago
  > This doesn't address timing attacks, which are why this is done in the first place. I don't follow. Surely the reason to hide usernames is not to prevent a timing attack that would reveal... usernames.
  • thisGuysAccount 12y ago
    I might be missing what you're not following, but here's a quick explanation (and a reason why it's not a concern) Correct username, correct password: takes 30ms to execute the code Correct username, incorrect password: takes 15 ms to execute the code Incorrect username: Takes 7 ms to execute the code. You fuzz usernames, you get one that takes 15 ms, you know that's a valid username. You then start working the password. Not necessary on most systems, because we're working at speeds that are measured in nanoseconds, and since we're using networks for many attacks, the delays are unpredictable and measured in (at least) milliseconds.
    • Dylan16807 12y ago
      I understand how the timing attack works. I don't understand how it's a justification for hiding usernames. "You need to try to hide A because if you're not careful they can find A." If anything the timing attacks weaken the argument against hiding usernames.
• westi 12y ago
  > This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. Timing attacks are solved by how you implement the backend checking code and not how you present the result to the end user in the most user friendly manner.
  • deleted 12y ago
    [deleted]
• tracker1 12y ago
  I don't see how what you say is really true in a system with properly hashed/salted passwords. SELECT "Id", "Hash", "Salt" FROM USERS WHERE "Email" = $input if (results.length == 0) return -1; //No record, bad user, return early... if (results["Hash"] != Hash(pwd.trim(), results["Salt"]) return -2; //invalid password
  • nanofortnight 12y ago
    Your code has precisely the timing attack he tried to describe in it. You're returning early when a user doesn't exist.
    • tracker1 12y ago
      So? I'm advocating showing the correct error message... a timing attack is irrelevant in this case. For that matter, adding a random 500-2000ms timer before returning a failed result would likely be as effective, and not lead to a bad user experience.
  • shabble 12y ago
    If you have an index on your "Email" field in the database, there may be discernible difference between the time taken to check the index and return '0 rows', vs getting a match and actually reading the appropriate data to build the result row. I don't know if there's a solution to that in the general scheme of things, other than making the variance of query times between no user and some user as small as possible.
    • tracker1 12y ago
      And, if you're returning the correct error message, it doesn't matter.. the whole point of a timing attack is to determine the difference. IMHO usability is more important. There are other ways to improve security. Rate limiting with < N failed attempts via an IP in under < X minutes.
• deleted 12y ago
  [deleted]
• deleted 12y ago
  [deleted]
• baddox 12y ago
  I feel like the variance in network latency is going to be an orders of magnitude larger than the extra time it takes to test a password.
  • TheLoneWolfling 12y ago
    Doesn't matter. Network latency variance just means you need to sample more. It doesn't prevent the attack.
    • baddox 12y ago
      So what, you're going to take a large number of samples for each username attempt?
  • biot 12y ago
    It is, but with a sufficiently large number of attempts you can account for jitter. A good summary (with links to existing research) can be found here: http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/ http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote...
• masklinn 12y ago
  > This doesn't address timing attacks, which are why this is done in the first place. This is not done because of timing attacks, it's done because of cargo-cultism and laziness. > The error shown isn't to dissuade people from using web pages to try to gain access to accounts - it's because the raw code itself doesn't know which is which Modern systems store passwords salted and hashed with KDFs. The stored hash must be retrieved before the provided password can be checked as you need the stored hash's work factor and salt, which are stored alongside (/as part of) the hash. Such a system necessarily knows which is which.
• SixSigma 12y ago
  That would make it an even worse pattern, your implementation leaking into your UI.