5 ms·

Out of curiosity, why is it an issue if you leak creation time?

by cdmckay 10mo ago

robertlagrant 10mo ago
Depends on the data. If you use a primary key in data about a person that shouldn't include their age (e.g. to remove age-based discrimination) then you are leaking an imperfect proxy to their age.
- lwhi 10mo ago
  So the UUID could be used as an imperfect indicator of a records created time?
  - benterix 10mo ago
    UUIDv7 but not UUIDv4.
    - lwhi 10mo ago
      I suppose timing attacks become an issue too.
      - wongarsu 10mo ago
        UUIDv7 still have a lot of random bits. Most attacks around creating lots of ids are foiled by that
kreetx 10mo ago
E.g, if your service users have timestamp as part of the key and this data is visible to other users, you would know when that account was created. This could be an issue.
mort96 10mo ago
Well you're leaking user data. I'm sure you can imagine situations where "the defendant created an account on this site on this date" could come up. And the user could have created that account not knowing that the creation date is public, because it's not listed anywhere in the publicly viewable part of the profile other than the UUID in the URL.
- nish__ 10mo ago
  Pretty much every social media app has a "Member since X" visible on public profiles. I don't think it's an issue.
  - mort96 10mo ago
    Who said I was talking about social media?
    - nish__ 10mo ago
      Well where else do users have public profiles?
      - 0x3f 10mo ago
        The whole point though is that the ID itself leaks info, even if the profile is not public. There are many cases where you reference an object as a foreign key, even if you can't see the entire record of that foreign key.
        nish__ 10mo ago
        I can't think of any.
        strbean 10mo ago
        Sending a friend request is an obvious example.
        nish__ 10mo ago
        Ok but in that case, why not use the user ID as the primary key?
- koakuma-chan 10mo ago
  Discord is doing fine.
bruce511 10mo ago
The issue will be very context specific. In other words to (reasonably) answer the question, we'd have to judge each application individually. For one example, say you were making voting-booth software. You really don't want a (hidden) timestamp attached to each vote (much less an incrementing id) because that would break voter confidentiality. More generally, it's more a underlying principle of data management. Not leaking ancillary data is easier to justify than "sure we leak the date and time of the record creation, but we can't think of a reason why that matters." Personally I think the biggest issue are "clever" programmers who treat the uuid as data and start displaying the date and time. This leads to complications ("that which is displayed, the customer wants to change"). It's only a matter of time before someone declares the date "wrong" and it must be "fixed". Not to mention time zone or daylight savings conversions.
- deleted 10mo ago
  [deleted]
Bombthecat 10mo ago
Admins, early users, founders, CEOs etc etc would have althe lowest creation time...
saaspirant 10mo ago
There was a HN comment about competitors tracking how many new signups are happening and increasing the discounts/sales push based on that. Something like this.
- JetSetIlly 10mo ago
  In a business I once worked for, one of the users of the online ordering system represented over 50% of the business' income, something you wouldn't necessarily want them to know. However, because the online ordering system assigned order numbers sequentially, it would have been trivial for that company to determine how important their business was. For example, over the course of a month, they could order something at the start of the month and something at the end of the month. That would give them the total number of orders in that period. They already know how many orders they have placed during the month, so company_orders / total_orders = percentage_of_business It doesn't even have to be accurate, just an approximation. I don't know if they figured out that they could do that but it wouldn't surprise me if they had.
  - pezezin 10mo ago
    This is also something that depends heavily on regulations. In my home country, invoice numbers have to be sequential by law, although you can restart the numbering every year.
    - hexbin010 10mo ago
      A global sequence, or sequence-per-account? I suspect the latter?
      - pezezin 10mo ago
        A sequence per "series", where a series can be a fiscal year, a department or category, etc. But I am not sure if you can have one series per customer, I only find conflicting information. You can have more details here, in the section "Complete invoice": https://sede.agenciatributaria.gob.es/Sede/en_gb/iva/facturacion-registro/facturacion-iva/contenido-facturas.html https://sede.agenciatributaria.gob.es/Sede/en_gb/iva/factura... https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6 https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6 (Spanish only)
natch 10mo ago
If your system (pseudo-) random number generator (RNG) is compromised to derive a portion of its entropy from things that are knowable by knowing the time when the function ran, then the search space for cracking keys created around the same time can be shrunken considerably. This doesn’t even rely on your system’s built-in RNG being low quality. It could be audited and known to avoid such issues but you could have a compromised compiler or OS that injects a doctored RNG.
dboreham 10mo ago
Apart from all the other answers here: an external entity knowing the relative creation time for two different accounts, or just that the two accounts were created close in time to each other can represent a meaningful information leak.

Out of curiosity, why is it an issue if you leak creation time?

by cdmckay 10mo ago

Out of curiosity, why is it an issue if you leak creation time?

Depends on the data. If you use a primary key in data about a person that shouldn't include their age (e.g. to remove age-based discrimination) then you are leaking an imperfect proxy to their age.

lwhi 10mo ago
So the UUID could be used as an imperfect indicator of a records created time?
- benterix 10mo ago
  UUIDv7 but not UUIDv4.
  - lwhi 10mo ago
    I suppose timing attacks become an issue too.
    - wongarsu 10mo ago
      UUIDv7 still have a lot of random bits. Most attacks around creating lots of ids are foiled by that

kreetx 10mo ago

E.g, if your service users have timestamp as part of the key and this data is visible to other users, you would know when that account was created. This could be an issue.

mort96 10mo ago

Well you're leaking user data. I'm sure you can imagine situations where "the defendant created an account on this site on this date" could come up. And the user could have created that account not knowing that the creation date is public, because it's not listed anywhere in the publicly viewable part of the profile other than the UUID in the URL.

nish__ 10mo ago
Pretty much every social media app has a "Member since X" visible on public profiles. I don't think it's an issue.
- mort96 10mo ago
  Who said I was talking about social media?
  - nish__ 10mo ago
    Well where else do users have public profiles?
    - 0x3f 10mo ago
      The whole point though is that the ID itself leaks info, even if the profile is not public. There are many cases where you reference an object as a foreign key, even if you can't see the entire record of that foreign key.
      - nish__ 10mo ago
        I can't think of any.
        strbean 10mo ago
        Sending a friend request is an obvious example.
        nish__ 10mo ago
        Ok but in that case, why not use the user ID as the primary key?
koakuma-chan 10mo ago
Discord is doing fine.

bruce511 10mo ago

The issue will be very context specific. In other words to (reasonably) answer the question, we'd have to judge each application individually. For one example, say you were making voting-booth software. You really don't want a (hidden) timestamp attached to each vote (much less an incrementing id) because that would break voter confidentiality. More generally, it's more a underlying principle of data management. Not leaking ancillary data is easier to justify than "sure we leak the date and time of the record creation, but we can't think of a reason why that matters." Personally I think the biggest issue are "clever" programmers who treat the uuid as data and start displaying the date and time. This leads to complications ("that which is displayed, the customer wants to change"). It's only a matter of time before someone declares the date "wrong" and it must be "fixed". Not to mention time zone or daylight savings conversions.

deleted 10mo ago
[deleted]

Bombthecat 10mo ago

Admins, early users, founders, CEOs etc etc would have althe lowest creation time...

saaspirant 10mo ago

There was a HN comment about competitors tracking how many new signups are happening and increasing the discounts/sales push based on that. Something like this.

JetSetIlly 10mo ago
In a business I once worked for, one of the users of the online ordering system represented over 50% of the business' income, something you wouldn't necessarily want them to know. However, because the online ordering system assigned order numbers sequentially, it would have been trivial for that company to determine how important their business was. For example, over the course of a month, they could order something at the start of the month and something at the end of the month. That would give them the total number of orders in that period. They already know how many orders they have placed during the month, so company_orders / total_orders = percentage_of_business It doesn't even have to be accurate, just an approximation. I don't know if they figured out that they could do that but it wouldn't surprise me if they had.
- pezezin 10mo ago
  This is also something that depends heavily on regulations. In my home country, invoice numbers have to be sequential by law, although you can restart the numbering every year.
  - hexbin010 10mo ago
    A global sequence, or sequence-per-account? I suspect the latter?
    - pezezin 10mo ago
      A sequence per "series", where a series can be a fiscal year, a department or category, etc. But I am not sure if you can have one series per customer, I only find conflicting information. You can have more details here, in the section "Complete invoice": https://sede.agenciatributaria.gob.es/Sede/en_gb/iva/facturacion-registro/facturacion-iva/contenido-facturas.html https://sede.agenciatributaria.gob.es/Sede/en_gb/iva/factura... https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6 https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6 (Spanish only)

natch 10mo ago

If your system (pseudo-) random number generator (RNG) is compromised to derive a portion of its entropy from things that are knowable by knowing the time when the function ran, then the search space for cracking keys created around the same time can be shrunken considerably. This doesn’t even rely on your system’s built-in RNG being low quality. It could be audited and known to avoid such issues but you could have a compromised compiler or OS that injects a doctored RNG.

dboreham 10mo ago

Apart from all the other answers here: an external entity knowing the relative creation time for two different accounts, or just that the two accounts were created close in time to each other can represent a meaningful information leak.