131–140 of 172 posts
Is there a way to verify a UUID was created by me? I want to avoid database lookups of UUIDs from malicious/manipulated URLs.
The filter needs to be stored somewhere, so if your workload is write-heavy you'd be replacing lookups with updates, but if it's read-heavy most DB lookups can be replaced with filter lookups.
Is there a way to verify a UUID was created by me? I want to avoid database lookups of UUIDs from malicious/manipulated URLs.
You'd have to trade that DB lookup with CPU cycles for a signature validation.
For example you can use HMAC.
You send the UUID and HMAC-of-UUID to the client.
The client sends back UUID + HMAC-of-UUID.
You re-calculate HMAC-of-UUID-provided-by-client (using your secret key).
If the calculated HMAC matches the HMAC provided by the client you have confirmation that the UUID was issued by you. Because without the secret key the client can't calculate the correct HMAC for a random or modified UUID.
Earlier quoted context omitted.
You’re not alone. I’ve been migrating my tables to use uuid instead of integers and have been using uuid whenever I have new tables, unless I have very good reason not to. Experience was my teacher.
Don’t UUIDs as primary keys totally destroy the performance because UUIDs aren’t sortable and thus wreak havoc with the index for the primary key?
Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…
It's actually worse than that. The first 3 groupings (textually) of the uuid might be little endian while the other 2 are big endian. Learning this cost me more time than I care to admit. https://en.wikipedia.org/wiki/Universally_unique_identifier#...
Note:
> 6.8. Opacity: UUIDs SHOULD be treated as opaque values and implementations SHOULD NOT examine the bits in a UUID to whatever extent is possible.
Earlier quoted context omitted.
You cannot fix this with an conversion because you do not know if your UUID is correct or needs conversion. DMI data for example has inconsistent endian-ness depending on the vendor. So if you have a UUID sticker on a new server, you still have two options which UUID the machine will send during PXE, either the printed UUID in big-endian encoding or in the microsoft mixed-endian encoding. Use BIOS boot instead of EFI…
Isn’t endianness marked by the variant field? 1 is IETF, 2 is Microsoft, and this can be inferred from the sticker.
Earlier quoted context omitted.
my personal favorite UUID replacement, when not concerned with external compatibility or standards-compliance: a 96-bit random value, base64-urlsafe encoded to 16 ASCII characters >>> import secrets >>> secrets.token_urlsafe(12) 'uUBpBk2eENDslHyw' with UUID, you can store it as a compact 16 bytes in a database, but it needs 36 characters if you want to embed it in a URL or a JSON payload. and there's a temptation to…
uuid is just what you said - 16bytes. you could presumably base64 that too...
Earlier quoted context omitted.
It's actually worse than that. The first 3 groupings (textually) of the uuid might be little endian while the other 2 are big endian. Learning this cost me more time than I care to admit. https://en.wikipedia.org/wiki/Universally_unique_identifier#...
Why would this matter (except when you build an index for a big database)? Note: > 6.8. Opacity: UUIDs SHOULD be treated as opaque values and implementations SHOULD NOT examine the bits in a UUID to whatever extent is possible.
Earlier quoted context omitted.
If you write it the naive way it works. uint8_t bytes[4]; uint32_t = bytes[0] The endianness is whatever you write in the indexing and will be the same across architectures.
Unfortunately, the naive way also turns out to be wrong in C. uint8_t gets promoted to a signed int when shifting, which in turn causes undefined behavior for specific input. One way of fixing this is casting to the desired type before the shift, thus avoiding surprising conversions. On a side note, compiler warnings and sanitizers help with this kind of stuff greatly, use them if you have the option: https://godbolt…
Agree. For clarity, the "specific input" in the example would be a bytes[0] value larger than 127.
This behavior is also explained here:
https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+no...
Is there a way to verify a UUID was created by me? I want to avoid database lookups of UUIDs from malicious/manipulated URLs.
There are 124 bits available. (Actually a little less but let's pretend only 4 bits are needed for the version to keep it simple.)
You'll have to decide how many are the ID and how many are the signature. Let's say 32 bits are your ID and the remaining 92 are the signature. (Adjust according to your own needs.)
Let's suppose your ID is 1. Now you need to hash that ID together with a private key using an HMAC algorithm. This signature will have more than 92 bits so trim your signature to this length.
Now build your UUID by combining the 32 bits of your ID with the 92 bits of the signature and four bits specifying version 8 (proprietary).
To test if a claimed UUID is yours, pull out the 32 bits of ID and repeat the process of signature and building a complete UUID. If the bits match, success! If not, its a fake UUID.
Now read the responses to this comment to find out why you shouldn't do this.
I used to be a big proponent of using UUIDs for database PKs but I've found them inherently difficult to work with. It's much easier to remember/recognize an integer based PK when troubleshooting a data problem. This isn't to say you shouldn't use UUIDs at all, but I much prefer to use an "ExternalId" column of UUID type if you don't want to expose your integer based PKs externally.
I do comparisons using ```::text like '%``` when debugging in a command line. Or just copy/paste the whole thing. Yes it's marginally more annoying than integers, but only marginally.
I have several times wondered why I was getting no match on a query. And then discovered that I was using a user_id on an account_id field. UUID's have saved me from shooting myself in the foot so many times.