Hacker News new | comments | show | ask | jobs | submit login
Why does Meetup use a massively long identifier in email verifications?
9 points by curiouslyme 103 days ago | hide | past | web | favorite | 3 comments
It's so long, it seems rather inefficient. Why?

Example: http://meet.meetup.com/wf/click?upn=pEEcc35imY7Cp0tG1yyTt-2BUBUoslNY-2BF5OpsN3Z-2B5GTP6dMs-2BjiVa79z-2BxCFoE0drJuI1EtUdyxnjPvAa2lBegHXkhLo3sGSLIKeLILvN49WNN69trj7APyfH86IArfi_UOCYJbMP7egxXfSOcMVtXoGiwcAh1owf-2F2SXfDH6qtGdLaPDQ2J-2BAHSDPPn3GNACaCM8fkS5c8B1bitAqQjLJUKWvK8nWogCDls-2BrGLd4LWpc2d4mG6rlc6uaYTcfDB5P1SQjPBo6Rj5FtPFUC86bPGH7Ck7fx69YEzOJvrJMji7BtRQxToTLB7S565BbWDFN183oUjE4c1dQhRB7Fu5hJNa4awX5o1sJDp19-2FLaE-2B8-3D




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.


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.


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: