I hope you've managed to fix this, because this is an obvious security issue. A long token is used precisely because it is long and unguessable. The shortened URL is subject to enumeration attacks which can be used to hijack accounts.
This. So much fun can be had by enumerating link shortener URLs. I've experimented with enumerating some services' URL schema. Most of the time the link pointed to innocuous things like Amazon affiliate links or whatnot. Sometimes you would find interesting content that made you go 'wow!', but that was very rare.
Suppose you have 64-bit one-time identifiers for password reset links. With base-85 encoding, it's 11 characters, short enough to even type manually.
I suppose a password-reset link should expire within an hour. Scanning the entire 64-bit space in an hour in search of a working password-reset link is infeasible: rate-limiting will prevent it, and monitoring will warn about the attempt.
A feasible attack vector could be on the generation algorithm, but I suppose a good link shortener won't use a simple predictable RNG.
... and you lost your argument.
There's a reason why there's a variant of Base64 designed for URLs.
Not really. Usually password reset tokens are only valid for 10 or 15 minutes. With some basic rate limiting, you can stop a single actor from accessing more than one of those links in 15 minutes.
And even if they work around that, you just ask the user to verify their email address when they click on the link. Being able to enumerate the reset tokens and guess the right email address at the same time is highly unlikely.
Attacker knowing some existing user email will go to "forgot password" view and type in the e-mail for the user they plan to attack. Then after will start bruteforcing the token.
It is highly unlikely they had rate limiting because they had long tokens there for a reason and most frameworks like Laravel for example which provide similar forgot password feature won't by default rate limit those tokens or at least haven't in the past. I am not up to date with current version of Laravel and I think it may be using signed urls instead. Which would also be obviously terrible if shortened.
So the original team who built forgot pw didn't expect someone in the future to start shortening those urls, so it is unlikely they figured rate limiting to be necessary in this case.
It would require in most cases conscious decision making and effort to specifically rate limit token guesses, likely to be out of scope.
Catch all rate limiting by IP wouldn't work either because it would be arbitrary to use botnet to bruteforce.
But in the OP example the e-mail/user was already in the url so included with the shortened url. In this case hacker could just try random short urls until they hit something and due to redirection also immediately know the e-mail.
How?
Everything you said is true for the implementation that was listed, but my point was short URLs for password reset aren't always bad, if other mitigations are in place, which should be in place anyway (rate limiting requests for password reset URLs and requiring verification of the email address).
In this scenario, no. We're talking about an attacker who is iterating over the ID space of a URL shortener in order to find a password-reset link that had been URL-shortened.
If that link only contains a token and not the user's email address then the attacker doesn't know the email, and asking them to provide their email on the password reset page would at least make it marginally less bad to url-shorten links containing password reset tokens. (But it's still a bad idea)
But well, yeah in a scenario where you truly have short tokens and someone is not trying to create the token for the e-mail themselves, but just trying to find vulnerable links, then yes, in this case it would help, but that's non-sense, just have longer tokens and you are fine, why force user having to do extra steps, when you can just have longer tokens.
It's not just unattached performers who are the threat. People of every relations hip status and profession could be attacking.