| ▲ | kvirani a day ago |
| Which I have to assume is rare, right? |
|
| ▲ | wongarsu a day ago | parent | next [-] |
| We used to leak approximate creation time all the time back when everyone used sequential keys. If anything sequential keys are far worse: they leak the approximate number of records, make it easy to observe the rate at which new keys are created, and once you know that you can deduce the approximate creation date of any key. UUIDv4 removes all three of those vectors. UUIDv7 still removes two of three. It doesn't leak record count or the rate at which you create them, only creation time. And you still can't guess adjacent keys. It's a pretty narrow information leakage for something you routinely reveal on purpose. |
| |
| ▲ | johnisgood 20 hours ago | parent | next [-] | | I often see sequential order IDs, and they get incremented by one, so I can guesstimate the amount of orders they get within a minute by creating my own orders. I watched this happen as I was intentionally removing and creating new orders (as they did not support modification of existing but not yet accepted ones). What may I do with this information though as an user that would be damaging? Legitimate question, intent is not harm, but I genuinely do not see how this is a bad thing. I can see it being bad for tracking IDs, but not order IDs, unless you are allowed to view any orders that do not belong to your account, which is just fundamentally bad security and using UUIDv4 or a random string would simply be obscuring security. | |
| ▲ | hinkley a day ago | parent | prev | next [-] | | It’s also industrial espionage on competitors or potential acquisitions. | | | |
| ▲ | blackenedgem a day ago | parent | prev [-] | | UUIDv7s are much worse for creation time though imo. For sequential IDs an attacker needs to be have a lot of data to narrow the creation time. That raises the barrier of entry considerably to the point that only a committed attacker could infer the time. With UUIDv7 the creation time is always leaked without any sampling. A casual attacker could quite easily lookup the time and become motivated in probing and linking the account further | | |
| ▲ | AdieuToLogic a day ago | parent [-] | | > For sequential IDs an attacker needs to be have a lot of data to narrow the creation time. When sequential integer ID's are externalized, an attacker does not need creation times to perform predictive attacks. All they need to do is apply deltas to known identifiers. |
|
|
|
| ▲ | wredcoll a day ago | parent | prev | next [-] |
| It seems wildly paranoid, even for securitt researchers. |
| |
| ▲ | ibejoeb a day ago | parent | next [-] | | There are some practical applications that are not necessarily related to security. If you are storing something like a medical record, you don't want use it as a public ID for a patient visit, because the date is subject to HIPAA. | | |
| ▲ | ownagefool 20 hours ago | parent | next [-] | | This is probably not really true. You wouldn't be publishing patient visits publically, the only folks that'd legitimatly see that record would be those which access to that visit, and they'd most likely need to know the time of said visit. This access should be controlled via AuthN, AuthZ and audited. You'd also generally do a lot of time-based lookups on this data; what visits do I have today, this week, and so on. You might also want an additional DateTime field for timezones and offsets, but the v7 is probably better than v4 for this usecase. | |
| ▲ | mulmen a day ago | parent | prev [-] | | But they would have to relate that ID to patient data like their identity right? The date alone cannot be a HIPAA issue. That means every date is a HIPAA violation because people go to the doctor every day. |
| |
| ▲ | oulipo2 a day ago | parent | prev | next [-] | | I remember in the cracking days, where we were trying to crack ElGamal encryption or other, we noticed when some code had been written in eg Delphi (which used a weak RNG based on datetime), then when you tried to guess when the code was compiled and the key were generated, you could get a rough timerange, and if you bruteforced through that timerange as a seed to the RNG, and tried to generate the random ElGamal key from that, you would widely reduce the range of possibilities (eg bruteforce 10M ints, instead of billions or more) | | |
| ▲ | noir_lord a day ago | parent | next [-] | | An online casino got hit a similar way a long time ago, iirc someone realised the seed for a known prng was the system clock, so you could brute force every shuffle either side of the approx time stamp and compare the results to some known cards (I.e. the ones you’d been dealt) once you had a match you knew what everyone else had. Always thought that was elegant (the attach not using the time as the seed). | | |
| ▲ | hipratham a day ago | parent [-] | | Can you not just add salt to seed and make it true random? seems like under engineered solution to me. | | |
| |
| ▲ | hinkley a day ago | parent | prev [-] | | I stopped airplane maintenance software from shipping with a particularly egregious form of this for SSL session key generation. It’s hard to get a good random seed on a real time operating system. I tell you hwut. |
| |
| ▲ | replygirl a day ago | parent | prev [-] | | it's not about the individual record, it's about correlating records. if you can sequence everything in time it gets a lot easier to deanonymize data | | |
| ▲ | Macha a day ago | parent | next [-] | | However, if your API has a (very common) createdAt field on these objects, the ability to get the creation time from the identifier is rather academic. | | |
| ▲ | inopinatus a day ago | parent | next [-] | | The concern is not limited to access of the full records. The concern extends to any incidental expression of identifiers, especially those sent via insecure side channels such as SMS or email. In most cases this forms a compliance matter rather than an open attack vector, but it nevertheless remains that one has to answer any question along the lines "did you minimise the privacy surface?" in the negative, or at least, with a caveat. | |
| ▲ | hinkley a day ago | parent | prev [-] | | And that’s why some people are rabid about “no SELECT *”. |
| |
| ▲ | tracker1 a day ago | parent | prev [-] | | Can you provide an example of where you would legitimately have the ID for a medical record interaction, but not a date/time associated? | | |
| ▲ | tyre a day ago | parent [-] | | Email is not secure but sending an email with a link to "Information about your appointment" is fine. If that link goes to `/appointments/sjdhfaskfhjaksdjf`, there is no leaked data. If it goes to `/appointments/20251017lkafjdslfjalsdkjfa`, then the link itself contains PHI. Whether creation date is PHI…I could see the argument being yes, since it correlates to medical information (when someone sought treatment, which could be when symptoms present.) | | |
| ▲ | ensignavenger a day ago | parent | next [-] | | Email may not be secure, but neither are faces and phones, and yet medical professionals use those all the time. | | | |
| ▲ | lazide 17 hours ago | parent | prev [-] | | Notably, this is an absurd argument. Every system I’ve dealt with right now sends the date/time/location/practitioner clear text in the email (or some variant thereof). The only thing that seems to be protected is ‘reason for appointment’, and not all systems do that. Everyone signs paperwork to authorize this when they first engage with the medical providers! |
|
|
|
|
|
| ▲ | a day ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | Too 21 hours ago | parent | prev [-] |
| Your comment here has id 45622189 and the UI tells me in plain sight that you posted it 11h ago. Assuming the ids are sequential, these two combined tells me more about HN vs a uuid ”leaking” something that’s already expected to be public. |
| |
