Hello UUIDv7! / wikipedia

• Exploring PostgreSQL 18’s new UUIDv7 support / HN - Unlike the traditional UUIDv4, which is completely random, UUIDv7 incorporates a timestamp as the most significant part of its 128-bit structure, allowing for natural sortability based on the creation time.
• UUIDv1 is generally not recommended since it leaks MAC addresses - people have been pwn’d due to this. It’s not a theoretical problem.
  • Step 1: Generate UUIDs using a highly predictable pattern
  • Step 2: Use the UUID as a security key - like saving a private file at files.example.com/12345678-1234-5678-1234-123456781234/private-file.pdf
    • and assuming nobody will be able to download it without knowing the UUID
  • Step 3: Attacker predicts the UUID and downloads the private file.

• Avoid UUID Version 4 Primary Keys in Postgres - This is incredibly database-specific. In Postgres random PKs are bad. But in distributed databases like Cockroach, Google Cloud Datastore, and Spanner it is the opposite

• We just had an actual UUID v4 collision… - This is surprisingly common.
  • The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what “high-quality entropy” actually means and that it is required for UUIDv4 to work as advertised.
  • It is relatively expensive to detect when an entropy source is broken, so almost no one ever does. They find out when a collision happens, like you just did.
  • UUIDv4 is explicitly forbidden for a lot of high-assurance and high-reliability software systems for this reason.