Hacker News Reader

Comment by judge2020 | Hacker News Reader

judge2020

So the reasoning makes it sound like there was potentially an exploit that made it easy to find unlisted videos? Were the video IDs deterministic perhaps?

View on HN

Yes, exactly. Video ID is just a base64'ed DES-encrypted primary int64 video key from MySQL. It used to be sequentially incremented until at some point they switched to randomly generated primary keys. Any (ex-) engineer who snapped a copy of the encryption key (it used to sit right in the code for anyone to see) can enumerate all videos from YT until that moment, including unlisted - which are only protected by secrecy of that one key. If the key leaks, then also anyone in the world can. That's what they are afraid of here. Source: worked for YT.

Just for curiosity, how would YT deal with ID collision ?

Edit: Before the scheme change I mean

Try again? Just a guess.

Probably they just roll again. You can even implement that in a stored procedure.

Not sure about technical details for that but perhaps something like https://vitess.io/docs/reference/features/vitess-sequences/. Vitess itself is a project that grew out of YouTube's needs to scale and shard their MySQL DB.

>base64'ed DES-encrypted primary int64

Block ciphers (such as DES) don't collide. If they did there would be no way to decrypt them because a block could be decrypted into multiple valid plaintexts.

Maybe their old scheme, when divided by the number of videos, was getting to the point where it was feasible you could brute force finding unlisted videos.

The old scheme had 7.3 x 10^19 ids (11 chars, base 64, thanks Tom Scott!). Suspiciously close to the max value of a 64-bit int, hmmm …

Assume a billion videos and you’re down to 10^10 - a one in a 10 billion chance isn’t much chance, but it’s far from secure.

(I’m ignoring the fact that only a small %age of videos are unlisted I guess, but I think the point still stands.)

Reply on news.ycombinator.com