[pritambarhate]

A little late to comment here. But for database IDs, I have found that Instagram's technique to generate IDs works very well: https://instagram-engineering.com/sharding-ids-at-instagram-...

They are not serially incrementing but still sortable. Thus prevent index fragmentation issues observed with UUIDS. Are 8 bytes in length. So index size is smaller compared to UUIDs. So you get all benefits of serial IDs but they are not easily guessable thus preventing sequential access attacks.

[orangepanda]

> With more than 25 photos and 90 likes every second

What unimaginable scale

[giansegato]

That was in 2012, when they "only" had 15M users

Today, a decade later, they're at 1.074B

[codeflo]

> they are not easily guessable

I don't see how that's true. From reading the article you linked, you only need a valid shard ID (which you can extract from known IDs), the millisecond (which is guessable) and a 10-bit sequence (which you can easily brute-force).

(And that's completely fine if their security model doesn't require unguessable IDs.)

[pritambarhate]

>> which you can easily brute-force

It will results in a very high number of 404s. These can be monitored and the origin IPs can be banned.

[codeflo]

2^10 is 1024, so hundreds of requests. Not a very high number. And since it’s a counter, even less. Easy to disguise; the official app is likely to do more requests in a one-minute session. And obviously, sophisticated attackers aren’t limited to one IP.

I’m suspecting you meant “easily guessable” in the human sense, not the cryptographic/security sense. My bad if I misunderstood you. Again, I’m not saying Instagram has any security problem, I’m just saying that this ID scheme in particular isn’t a security feature.