3 ms·

IMO, this is bad math and why you probably need to be more cautious. I actually went through similar math with my team last year. * It's long been know that UU

IMO, this is bad math and why you probably need to be more cautious. I actually went through similar math with my team last year. * It's long been know that UUID should never be used as a security mechanism. While the math is interesting, the fact they're using it as justification for moving away from UUIDs is concerning. It'd be like publishing a post titled "we're moving away from MD5" * If you're using these tokens for human-entered purposes, you should implement account based rate limiting. It's nearly impossible for a brute force attack if a single account can only have, say 100 attempts per day before contacting support. There are very very use cases where a human-based token will ever need more than 20 attempts per day. * Use long, high-character count tokens if they're intended to be machine/copy-n-paste only. Storage is cheap. Use something big and long. Seriously, rate limit your shit. The second that rate limits are introduced you control all of the major variables in your security posture.

dopidopHN 4y ago
Exactly the article glossing over rate limiting and proceeding to do some math without it kinda ruined the article for me. The minute is rate limited it’s crumble.
skybrian 4y ago
If the attacker doesn't care which account they break into, they could try a different account each time and then account-based rate limiting doesn't help as much. (Depending on how many accounts there are that they can try.)
- SkyPuncher 4y ago
  Generally, the subject tokens (short-ish, human enterable tokens) should only be active on a fraction of your accounts at any one time.
- pkulak 4y ago
  Hopefully they aren't able to get a list of all your user accounts. The IDs should not be iterable (like a UUID, for example!), and the friendly name (like an email address) is private information that shouldn't be getting out.
tgv 4y ago
I've got a UUID in the URL of a new system (not a real UUID, but 128 random bits encoded in the UUID format), because that kept the existing links active. If someone were to guess one (which isn't that interesting, BTW, it's not account info or anything like it), he'd have a hard time checking a million per second, because the response is never going to be faster than 10ms or so.

dopidopHN 4y ago

Exactly the article glossing over rate limiting and proceeding to do some math without it kinda ruined the article for me. The minute is rate limited it’s crumble.

skybrian 4y ago

If the attacker doesn't care which account they break into, they could try a different account each time and then account-based rate limiting doesn't help as much. (Depending on how many accounts there are that they can try.)

SkyPuncher 4y ago
Generally, the subject tokens (short-ish, human enterable tokens) should only be active on a fraction of your accounts at any one time.
pkulak 4y ago
Hopefully they aren't able to get a list of all your user accounts. The IDs should not be iterable (like a UUID, for example!), and the friendly name (like an email address) is private information that shouldn't be getting out.

tgv 4y ago

I've got a UUID in the URL of a new system (not a real UUID, but 128 random bits encoded in the UUID format), because that kept the existing links active. If someone were to guess one (which isn't that interesting, BTW, it's not account info or anything like it), he'd have a hard time checking a million per second, because the response is never going to be faster than 10ms or so.