It seems wildly paranoid, even for securitt researchers.

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 a day 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.

	▲	lazide 18 hours ago \| parent [-]
		Difficulty - they used the date as the salt.

▲

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.

	▲	ensignavenger 18 hours ago \| parent [-]
		Fat fingered fax... faxes, not faces!

▲

lazide 18 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!