5 ms·
Add "help avoid sending teenagers to prison" to the list of reasons why you should prefer UUIDs over integers in your Internet-facing REST API. This API was su
by politician 9y ago
Add "help avoid sending teenagers to prison" to the list of reasons why you should prefer UUIDs over integers in your Internet-facing REST API.
This API was supposed to be private and yet supported trivial enumeration?
- Someone1234 9y agoMany UUIDs aren't secure either and can be trivially enumerated. A better approach might be a long number generated using a secure random number generator and converted to a BASE-64 string.
- Wald76 9y agoGenerally you generate a random UUID which is quite difficult to enumerate.
- kbar13 9y agouuidv4 is random assuming your rng source is random
- Someone1234 9y agoAnd assuming you're legitimately getting a UUIDv4 instead of a UUIDv1 or UUIDv2 now and forever...
- larkeith 9y agoA better approach would be to not put private data in the public domain.
- thisacctforreal 9y agoI think a cryptographic hash is fine. If you know the hash, you likely already know the file.
- Someone1234 9y agoA cryptographic hash of what? Cryptographic hashes aren't random by nature.
- thisacctforreal 9y agoThe document, from what I could glean they were PDFs. Edit: even if they aren't PDFs, you can feed the content to the hash function.
- Someone1234 9y agoI suppose that might work but seems needlessly complex compared to just a long securely generated random number.
- evincarofautumn 9y agoYeah, randomly generated IDs are fine for most use cases IMO, and perhaps more importantly they’re easy to implement well enough—grabbing 256 bits from /dev/urandom isn’t bad. With a hash it’s more expensive to compute the ID, but you get advantages such as content-addressability, data integrity without trust, and easily mergeable databases. It’s a good amount of bang for not much more buck. At the cost of leaking more metadata in the ID, by including a checksum/namespace, you can recognise a valid ID or determine the type of object it refers to without fetching anything from storage, mitigating some DOS attacks. IDs are a subtle thing, and in my experience, often overlooked as a design issue. A lot of times it ends up as something like “id integer primary key autoincrement” without any thought.
- goshx 9y agoIf things should be secure, they should be behind authentication and authorization for that content. To argue about what is the best ID to be used is just trying to fix what is not broken, IMHO.
- quickthrower2 9y agoSecurity is multi layered.
- scrumption 9y agoObscurity is not a security layer.
- Someone1234 9y agoSo a password or private encryption key isn't security?
- deleted 9y ago[deleted]
- rurounijones 9y agoObscurity is a perfectly fine security layer as you said yourself (i.e. it is one of many layers). Relying ONLY on obscurity is a failure.
- pluma 9y agoWhat is a UUID if not a fairly predictable object-based shared authorization token? EDIT: I'm mostly kidding.
- quickthrower2 9y agoJust call it an object-specific API key, that forms part of the URI instead of being a header value. Since we are using https it's all good.
- gruez 9y ago>Many UUIDs aren't secure either and can be trivially enumerated. uuidv4
- drew-y 9y agoIf the information is supposed to be private wouldn't you want to use token based auth or something similar? I wouldn't feel comfortable exposing information publicly even if it was behind a UUID.
- politician 9y agoSure, but remember the lowest-bid contractor here used an integer. Baby steps.
- mr_toad 9y agoUUID are easily shared, and there is no way of knowing who shared it. Good for Xmas photos, not so good for sensitive documents.
- jessaustin 9y agoYou could just keep a record of to whom you gave each UUID?
- mlazowik 9y agoThe thing is it wasn't even supposed to be private! https://twitter.com/SwiftOnSecurity/status/985365624141512704 https://twitter.com/SwiftOnSecurity/status/98536562414151270...