3 ms·

Can you ever (safely) include credentials in a URL?

• BenjiWiebe 6y ago
  You can "probably" get away with 64 bits and modest rate limiting?! At 1 million requests a second, that's half a million years to try every possibility. So 250k years for a 50% chance of guessing a random 64 bit token. 64 bits is a lot! And very few web apps can handle a million requests per second.
  • nmadden 6y ago
    Two points: Your calculations assume that attackers are interested in brute forcing one particular token. But if your app issues a lot of tokens then it becomes easier for an attacker to find some valid token. For example, if you issue a billion tokens and allow a thousand requests per second then I can find one of those tokens in about 100 days. Is that realistic? Maybe not, but it’s a lot lower than 250k years. The second point is that I’ve several times in my life seen code that logs a hash of a security token to allow easy correlation of requests. Such a hashed log is then vulnerable to offline brute force attacks with very many more than a million guesses per second.
    • karmakaze 6y ago
      The first point is what was in the post as being tied to the resource. Don't pass tokens to /me, instead to /user/name that way having a valid token is only half the solution.
      • nmadden 6y ago
        (Author of the post here). My point is that you can easily make this a complete non-issue by increasing the entropy of the token. 96-bit tokens are 16 characters in base64url - just 3 more characters than the 64-bit tokens used by Waterken, yet with a token space 4 billion times as large. By way of contrast, Google Docs URLs include a random string that is over 40 characters long.