
Why does Meetup use a massively long identifier in email verifications? - curiouslyme
It&#x27;s so long, it seems rather inefficient. Why?<p>Example:
http:&#x2F;&#x2F;meet.meetup.com&#x2F;wf&#x2F;click?upn=pEEcc35imY7Cp0tG1yyTt-2BUBUoslNY-2BF5OpsN3Z-2B5GTP6dMs-2BjiVa79z-2BxCFoE0drJuI1EtUdyxnjPvAa2lBegHXkhLo3sGSLIKeLILvN49WNN69trj7APyfH86IArfi_UOCYJbMP7egxXfSOcMVtXoGiwcAh1owf-2F2SXfDH6qtGdLaPDQ2J-2BAHSDPPn3GNACaCM8fkS5c8B1bitAqQjLJUKWvK8nWogCDls-2BrGLd4LWpc2d4mG6rlc6uaYTcfDB5P1SQjPBo6Rj5FtPFUC86bPGH7Ck7fx69YEzOJvrJMji7BtRQxToTLB7S565BbWDFN183oUjE4c1dQhRB7Fu5hJNa4awX5o1sJDp19-2FLaE-2B8-3D
======
db48x
It's not likely to be an identifier. It's most likely a base64-encoded JSON,
or some other similar encoding, followed by an HMAC. Probably the encoded data
includes a nonce too, which is a largish random number.

Why write something to a database if you can stick it in the url instead? When
you stick it in the url it lasts exactly as long as a user is interested in
it. If you stick it in a database and give out an identifier you then have to
expire it out of the database some time later. This either disappoints users
because you expired it too soon, or costs you to store it for longer than it
was needed. The HMAC ensures that they can ignore any data that was modified
by a curious hacker.

------
jwilliams
That looks like a white-labelling (i.e. custom domain) of SendGrid's click
tracking feature.

As db38x noted, SendGrid is likely encoding a bunch of data in the link to
keep things simple/fast on the back end. Possibly it's the actual target URL
and some associated data like the link text.

It's also likely that they're conservative on the encoding they use to prevent
issues with different email clients (looks like Alphanumeric, dash and
underscore only).

That saves them tracking all that data in a database, which I presume at
SendGrid's scale is quite a lot.

~~~
curiouslyme
Ah - I had not considered SendGrid.

From an absolute security perspective, using some sort of hash or similar
unique ID then referencing a database seems like the strongest solution.

But you are right, at large scale encoding the data in the URL plus some sort
of HMAC would provide strong security with no database overhead, which I'm
sure becomes significant at scale.

Might be interesting to try and reverse engineer their approach. Hash
algorithms have a rather long history of being proven weaker than hoped...
Especially down the road this could lead to some interesting possible
exploits, mostly if the link was related to some kind of account a little more
sensitive than meetup.com

Thanks for clarifying my thinking on this matter...

