6 ms·

So one of the issues here is using an externally visible ID (or a transformation of such) as an internal ID. Why not create a random int64 at account creation t

So one of the issues here is using an externally visible ID (or a transformation of such) as an internal ID. Why not create a random int64 at account creation time which is invisibly linked to the public username (eg, email address). So now you've got a proper join key, you can restrict access to the map, and it's easy to delete the map entry when the user unsubscribes. (There can still be good reasons to apply one-way hashing to the random internal UUID, as well: for example, to provide different levels of logs access to different internal users. People who make dashboards get hashed ids, and people who debug logging get raw ids.) The problem of entropy allowing individual user identification even with all IDs scrubbed is still very real, though, and non-trivial to undertake. One can start by wrapping the query engine with a service which checks that a certain minimum number of people are covered by a given query before returning the results. Or apply differential privacy-type transformations to the output...

kevin_nisbet 9y ago
This is along the lines of where I was going with the alternative approach, I just simplified it for brevity. :) In the case of teleport, I think this is a bit more difficult to achieve, because we don't necessarily have our own account database, our common commercial use case is integrated to an identity provider through SAML/OIDC, which I'm not sure would consistently offer a random id per account to use. While there are many way's we could generate and store the username <-> random id mappings, this adds a certain amount of complexity to get right on a distributed system. If building a system from scratch with end to end control, I do prefer the random identifier approach.
merinowool 9y ago
Then user emails you to ask what personal data of his you have on the server. Now you don't have a connection so you can't find it, but you have it. GDPR non compliance.
- unilynx 9y ago
  If you can't connect it to the user in any way, it's no longer personal information. Expect the data protection agency to compliment you.
  - JumpCrisscross 9y ago
    > If you can't connect it to the user in any way, it's no longer personal information Just because you can't connect it doesn't mean nobody else can.
    - GordonS 9y ago
      For all practical purposes, a secure, one-way cryptographic hash is irreversible.
      - shabble 9y ago
        I'm thinking of a number between 1 and 100. It's bcrypt hash is: '$2b$15$qUxzZ5ZF55lMuqiH9GMjQOHkNyee86qd2Vh2kQyF5P3U6JZJx9AEC' I bet nobody could ever reverse this secure cryptographic hash to figure out what it could be... ;)
      - Nomentatus 9y ago
        I think you need to address converse the examples in the article in order to assert this.
    - unilynx 9y ago
      http://www.privacy-regulation.eu/en/r26.htm http://www.privacy-regulation.eu/en/r26.htm ... account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. ... It's sufficient if one can't reasonably reconnect the data back to the user. It doesn't need to be NSA-proof.
- sdenton4 9y ago
  It's your mapping, so you can easily gather up everything with the given marker and hand it back to them. You only throw away the key (and delete attached data) if the user deletes their account (and maybe after some additional time elapses, in case they change their mind or were hacked); it's the same process as GDPR per-user encryption key deletion.
  - merinowool 9y ago
    If you throw away the key you still have the data but encrypted. There is no guarantee that in 5 years user data could be easily decrypted.
    - JetSpiegel 9y ago
      Well, the NSA slurps all Internet traffic, so by that definition, no encrypted communication is possible.
    - Thiez 9y ago
      But there's no reason to believe that will be possible either. By that same reasoning it might be possible 'in 5 years' to recover the erased (and overwritten) data from the storage device, so you never can delete anything. If you use something such as AES 256, which is approved for use to encrypt 'top secret' information by the NSA, and through some miracle it turns out that we can easily decrypt such data in 5 years, then I'm pretty sure you can argue in court that you were following best practices and had no reasonable way of predicting this encryption disaster.
    - sdenton4 9y ago
      'Key' here refers to the key in the mapping from external to internal userID. The whole point is that (as mentioned in a sibling comment) choosing an internal user ID uniformly at random is equivalent to a one-time pad; it's guaranteed non-decryptable, unless you invent a time machine...
      - robbiemitchell 9y ago
r00fus 9y ago
Isn't this essentially the uuid() function that many databases support natively (even the black sheep MySQL)?

kevin_nisbet 9y ago

This is along the lines of where I was going with the alternative approach, I just simplified it for brevity. :) In the case of teleport, I think this is a bit more difficult to achieve, because we don't necessarily have our own account database, our common commercial use case is integrated to an identity provider through SAML/OIDC, which I'm not sure would consistently offer a random id per account to use. While there are many way's we could generate and store the username <-> random id mappings, this adds a certain amount of complexity to get right on a distributed system. If building a system from scratch with end to end control, I do prefer the random identifier approach.

merinowool 9y ago

Then user emails you to ask what personal data of his you have on the server. Now you don't have a connection so you can't find it, but you have it. GDPR non compliance.

unilynx 9y ago
If you can't connect it to the user in any way, it's no longer personal information. Expect the data protection agency to compliment you.
- JumpCrisscross 9y ago
  > If you can't connect it to the user in any way, it's no longer personal information Just because you can't connect it doesn't mean nobody else can.
  - GordonS 9y ago
    For all practical purposes, a secure, one-way cryptographic hash is irreversible.
    - shabble 9y ago
      I'm thinking of a number between 1 and 100. It's bcrypt hash is: '$2b$15$qUxzZ5ZF55lMuqiH9GMjQOHkNyee86qd2Vh2kQyF5P3U6JZJx9AEC' I bet nobody could ever reverse this secure cryptographic hash to figure out what it could be... ;)
    - Nomentatus 9y ago
      I think you need to address converse the examples in the article in order to assert this.
  - unilynx 9y ago
    http://www.privacy-regulation.eu/en/r26.htm http://www.privacy-regulation.eu/en/r26.htm ... account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. ... It's sufficient if one can't reasonably reconnect the data back to the user. It doesn't need to be NSA-proof.
sdenton4 9y ago
It's your mapping, so you can easily gather up everything with the given marker and hand it back to them. You only throw away the key (and delete attached data) if the user deletes their account (and maybe after some additional time elapses, in case they change their mind or were hacked); it's the same process as GDPR per-user encryption key deletion.
- merinowool 9y ago
  If you throw away the key you still have the data but encrypted. There is no guarantee that in 5 years user data could be easily decrypted.
  - JetSpiegel 9y ago
    Well, the NSA slurps all Internet traffic, so by that definition, no encrypted communication is possible.
  - Thiez 9y ago
    But there's no reason to believe that will be possible either. By that same reasoning it might be possible 'in 5 years' to recover the erased (and overwritten) data from the storage device, so you never can delete anything. If you use something such as AES 256, which is approved for use to encrypt 'top secret' information by the NSA, and through some miracle it turns out that we can easily decrypt such data in 5 years, then I'm pretty sure you can argue in court that you were following best practices and had no reasonable way of predicting this encryption disaster.
  - sdenton4 9y ago
    'Key' here refers to the key in the mapping from external to internal userID. The whole point is that (as mentioned in a sibling comment) choosing an internal user ID uniformly at random is equivalent to a one-time pad; it's guaranteed non-decryptable, unless you invent a time machine...
    - robbiemitchell 9y ago

r00fus 9y ago

Isn't this essentially the uuid() function that many databases support natively (even the black sheep MySQL)?