News for hackers. Stuff that matters.
Re:First American Financial Corp. Leaked Hundreds of Million... by prophesi on Friday May 24, 2019 @08:08PM (#20006316)
I think this gets to the crux of the issue.

It's not about using hard-to-guess UUIDs[0], but restricting access to the underlying data[1].

[0] https://en.m.wikipedia.org/wiki/Security_through_obscurity

[1] https://en.m.wikipedia.org/wiki/Access_control

Re:First American Financial Corp. Leaked Hundreds of Million... by cm2187 on Friday May 24, 2019 @10:24PM (#20006740)
It's not really security through obscurity. In these case I understand the ids where related to data that the company was making available to users through email links. A cryptographically secure 128bit UUID is impossible to guess, no more than a cryptographic access token. Now of course, you would probably rather want to have an authentication scheme on top of that, but that comes at a support cost in term of customers loosing their passwords, locking themselves out of their account, etc. And it is not clear you have increased security as people re-use passwords.

Then of course there is the issue that email is for the most part un-encrypted (or encrypted without validating certificates).

Re:First American Financial Corp. Leaked Hundreds of Million... by prophesi on Saturday May 25, 2019 @09:12PM (#20012529)
It's still an access control issue in that case. The user should never be aware of the UUID's. Only the backend should deal with it. If you have a _public_ API that deals with UUIDs, therein lies the issue.

And a side note: I wouldn't trust that the prng for your UUIDs are cryptographically secure. That's not a part of the spec.