Hacker News Reader

Comment by chias | Hacker News Reader

I worked with an org that ran their own link shortener... and used it for confirmation links! I'm not even kidding, you'd go to reset you password and as expected the link would be something like:

    ourapp.example.com/auth/reset?user=blah&token=1af17e73721dbe0c40011b82ed4bb1a7dbe3ce29eae4997c84600287f8866673d05fdaa1aa841a5a

and they they figured, oh man, those links are unsightly for email, we'd best turn that into something like:

    ourapp.example.com/s/xO8pR

That looks way cleaner in an email.

View on HN

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.

Yeah. When I stumbled across this I had some conversations, with the net result that URLs containing authenticator tokens are no longer shortened :)

> A long token is used precisely because it is long and unguessable

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.

Well, no.

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.

> With base-85 encoding

... and you lost your argument.

There's a reason why there's a variant of Base64 designed for URLs.

> because this is an obvious security issue

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.

Verifying their e-mail address would be useless as attacker would already know the e-mail.

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.

> Verifying their e-mail address would be useless as attacker would already 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).

The attacker would start out with a targeted user's email or login to the site. A personal email address usually is usually public. Start the password recovery process. Use a botnet to try different shortened links. A rate limit on password reset for an account would help if the attacker had low probability of success before the reset link expired, but the attacker can cycle between multiple target accounts.

> Verifying their e-mail address would be useless as attacker would already know the e-mail.

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)

My point is that they don't have to iterate over all e-mails as long as they know at least one e-mail of any user, which doesn't seem that far fetched, as they can just simply trigger creation of this token for that particular e-mail themselves. It's especially effective if it's a targeted attack.

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.

> you can stop a single actor

It's not just unattached performers who are the threat. People of every relations hip status and profession could be attacking.

I doubt they implemented rate limiting though.

Here’s some more baseless guesswork: I am absolutely certain they did.

I said "I doubt", you said "I am absolutely certain". Can you tell the difference?

Effectively there's no difference, both statements are equally worthless.

I doubt he can

On the URL shortener, or on the password reset token endpoint? Because only one of those will save you.

Well, one more place and a simple base 36 alpha/numeric shortened token like this can represent a number up to around two billion so good luck with the enumeration attack - especially if you have a reasonable rate limiting scheme for requests. 2FA tokens are usually even simpler.

The first link is a hex encoded token, 80 chars, 4 bits per char = 320 bits of information. The second shortened link key is likely base 64 encoded, 5 chars, 64 bits per char = 320 bits of information. These should be basically the same from a security perspective. Is there something I'm missing here that you're suggesting?

Edit: This is wrong and should be 30 bits of information not 320 bits for the shortened form. 64 values = 6 bits not 64 bits.

> The second shortened link key is likely base 64 encoded, 5 chars, 64 bits per char

No, 64 values – or 6 bits. 6×5=30, not 320.

Ah, RIP, my math is incorrect. Thanks.

base64 -> 64 possibilities -> 6 bits I guess?

We also don't know if the shortened urls are random.

I think it's usually base62.

You can also use an alternate alphabet like this one https://base64.guru/standards/base64url which replaces +/ with -_ which are URL safe characters.

Probably is. Base64 includes + and / which I believe need to be URL encoded, plus the = padding can mean an extra step if you want to remove them to make the URL pretty.

https://en.wikipedia.org/wiki/Base64#Base64_table

https://www.kerstner.at/2012/07/shortening-strings-using-bas...

> 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?

Require the user to enter their user id again.

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.

Clearly the user id would be removed from the URL, and rate limiting can be done by IP address.

…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)

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.

How would you rate-limit an unauthenticated-by-definition endpoint?

By IP. It doesn't have to be limited by much, just enough to discourage brute force attempts.

Assuming any of it is being actively monitored.

Also, I never click on links in e-mails directly. For something like this I'd cut and paste the address it seems Google puts another layer of redirection in Gmail to spy on you ("data-saferedirecturl", whatever that does in their JS)

It's a valve they can shut off when the targets are detected to be phishing or malware, so the link breaks.

And, of course, tracking.

Since they control the rendering, they can shut it off by not hyperlinking the link or displaying a warning next to it, they don't need to put an always-on tracking mechanism in place that sends them click data even when the link is not determined to be malware.

I imagine that many organizations would like to know which of their employees did click a link that turns out to be malicious, so that the company can check those employees' computers for malware. Tracking could be useful for determining the severity of the damage done by a successful phishing attack.

For corporations on corporate computers fine, but this is Google tracking personal accounts.

Gmail can track when you cut the URL...

ah yes, let me instead manually type the url into a new chrome tab, google will have no idea I went there.

I'm not sure if this is still the case but there was a period of time when email clients would not transform the entire URL into a clickable link if it was too long. These were generally email clients which supported plain text only.

Anyway, I think that I'd be okay with a shortener like your example as long as it:

1. Required me to enter my user id again 2. Was only valid for 30 minutes

Outlook desktop client still has problems with really long links in that although they remain clickable, they don't actually go anywhere.

Yeah, we do that. It's simple and easy, allows us to tweak the destination of a published link if the site shuffles, lets us print simple short links that are quick to type but still are obviously our own domain.

You can't do it for everything... for one thing, you don't gain search engine karma from the links. But it's often very useful.

Do you also do that for links with secret tokens like the reset password link the op mentioned? Because -spoiler- that makes those links very easy to guess/brute force

No, I should have made that clear. Don't do it for links including tokens, user accounts, or anything like that. (Obviously.) Only on links you'd put out for mass consumption.

Still, it can eliminate lots of unsightly cruft in a link. It can replace this: https://thisonecompany.com/productinfo/specs/?sku=sdfdf432&f...

with: https://this.co/proddeets

There are many valid use cases for URL shortener, I am not sure if this is one of them.

IMHO, this is a display layer issue that only affects human eyes, and should be handled on display layer (html, email rendering...etc) -- just don't display the whole URL somehow. Machines won't have any problem processing that long link.

Some platforms do this. My understanding is that they're especially motivated by the fact that many people don't really distinguish between mybank.com/changepassword and mybank.attacker.com/changepassword.

However, it really infuriates some vocal technical folks (e.g. https://www.androidpolice.com/2020/08/13/google-resumes-its-...). I think the compromise is good: hide the full URL by default, but have a setting or some affordance to show the full thing to people who do enjoy looking at it.

Reply on news.ycombinator.com