4 ms·

> ourapp.example.com/s/xO8pR Wow. And makes it easier to brute-force (Which I think you're insinuating). If the links have an auto-expire of 10 minutes, is the

> ourapp.example.com/s/xO8pR Wow. And makes it easier to brute-force (Which I think you're insinuating). If the links have an auto-expire of 10 minutes, is the risk sufficiently mitigated? Or am I missing something else?

fullstop 5y ago
Require the user to enter their user id again.
- nneonneo 5y ago
  …and make sure that the original URL doesn’t include the user ID anywhere - it did in OP’s original example, which means that any attacker could scrape the ID just by watching what the redirect went to (assuming a normal link shortening service was used)
  - fullstop 5y ago
    Right, that was implied. You'd need to rate-limit the shortened URL endpoint as well or increase the number of characters. Without it, you could reset a user's password and brute force all shortened possibilities while entering their username. There'd be enough red flags to identify and stop this type of behavior, I think.
    - mewpmewp2 5y ago
      Assuming any of it is being actively monitored.
    - chias 5y ago
      How would you rate-limit an unauthenticated-by-definition endpoint?
      - fullstop 5y ago
        By IP. It doesn't have to be limited by much, just enough to discourage brute force attempts.
- chias 5y ago
  Wouldn't help much with it right there in the URL too. Even if it weren't, triggering a password reset for somebody and then fuzzing the url space ends up working pretty quick. I saw a few comments talking about rate limiting but since these are by definition unauthenticated requests, that's not going to help you either. Short version (heh) is you cannot make this secure.
  - fullstop 5y ago
    Clearly the user id would be removed from the URL, and rate limiting can be done by IP address.