4 ms·
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.wi
by prophesi 7y ago
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 https://en.m.wikipedia.org/wiki/Security_through_obscurity
[1] https://en.m.wikipedia.org/wiki/Access_control https://en.m.wikipedia.org/wiki/Access_control
- cm2187 7y agoIt'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).
- prophesi 7y agoIt'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.