Timeline for Protecting against malicious duplicate IDs in a distributed environment
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 25, 2024 at 7:06 | comment | added | Philippe | If a client (say a native app or web app) requires to know the id before creation, an allocator could be a useful pattern. whereby the client were to allocate a block of IDs (say UUIDv4), from the service beforehand. The specific service could then upon receiving these IDs know they are valid (by some kind of certification maybe) and unique (it created the ID before and knows if it is already used) and allow creation of entities with these new IDs. This solution would be somewhat constrained, but it would solve an (imho) important use case. | |
| Apr 25, 2024 at 3:20 | comment | added | Steve | Essentially he asks, "I run a lottery where people freely choose their own numbers; how do I ensure the same number is not picked twice, by anybody, ever? Including the case where the same person, since he can choose his own number, may try to play the same number twice.". Maintaining a central register of allocated numbers, and consulting it so as to veto any duplicate proposal, seems to me to be the only possible method. (2/2) | |
| Apr 25, 2024 at 3:20 | comment | added | Steve | @isanae, I must admit I can't find a straightforward description of exactly how v4 works. But the essence of the technique is that, if you pick a long enough lottery number using a PRNG, it is very unlikely to collide with another. However I think we have got sidetracked - the OP asked about "malicious" duplicates, the only possible interpretation of which (I realise clearly now) is that the allocation algorithm itself is not under the central control of the OP. (1/2) | |
| Apr 24, 2024 at 22:03 | comment | added | anon | @Steve GUIDs that use the MAC address are V1 and V2, I don't think they're used much anymore, it's all V4, which is random. See GUID versions. | |
| Apr 24, 2024 at 20:42 | comment | added | Steve | @DocBrown, my recollection of GUIDs is that it's based partly on the MAC address of the allocator (MACs being allocated centrally), and partly on the time of allocation (assumed to be fine-grained enough to make every allocation occur at a uniquely numbered moment). And collisions are only very unlikely in a single context of use, not guaranteed to be "globally unique" despite the name. | |
| Apr 24, 2024 at 20:13 | comment | added | Doc Brown | I think the logic of this answer is flawed. The standard method of creating unique IDs without a central registry is to use GUIDs. The prefixes for each allocator can be GUIDs as well. | |
| Apr 24, 2024 at 14:12 | comment | added | Steve | @BartvanIngenSchenau, exactly. Essentially, a block is allocated from the central registry to a service at compile-time. There is no possibility of reallocation at runtime (nor is there necessarily any need), and the coordination with the central registry occurs through the process of recompiling and distributing the software itself from a central source. | |
| Apr 24, 2024 at 13:53 | comment | added | Bart van Ingen Schenau | To add, if you base the prefix on the service (type) handling the request, the central authority for those prefixes could be a document in the development environment (i.e., to get a new prefix, the service needs to be modified, rebuilt and re-deployed). | |
| Apr 24, 2024 at 12:28 | history | answered | Steve | CC BY-SA 4.0 |