Comment séparer l'identité d'une personne à partir de ses données personnelles?

https://stackoverflow.com/questions/3691348

02-10-2019
|

Question

J'écris une application dont le but principal est de garder la liste des utilisateurs les achats.

Je voudrais assurer que moi-même en tant que développeur (ou toute personne ayant plein l'accès à la base de données) ne pouvait pas comprendre comment beaucoup d'argent personne en particulier a passé ou ce qu'il a acheté.

Je suis venu d'abord avec le schéma suivant:

    --------------+------------+-----------
    user_hash     | item       | price
    --------------+------------+-----------
    a45cd654fe810 | Strip club |     400.00
    a45cd654fe810 | Ferrari    | 1510800.00
    54da2241211c2 | Beer       |       5.00
    54da2241211c2 | iPhone     |     399.00

L'utilisateur se connecte avec le nom d'utilisateur dans et mot de passe.
le mot de passe calculate user_hash (éventuellement avec salage, etc.).
Utilisez le hachage aux utilisateurs d'accéder aux données avec requêtes SQL normales.

Étant donné suffisamment d'utilisateurs, il devrait être presque impossible de dire combien l'argent un utilisateur particulier a passé en tout connaître son nom.

Est-ce une chose sensée à faire, ou suis-je complètement fou?

La solution

Le problème est que si quelqu'un a déjà accès à la base de données, il est juste une question de temps avant qu'ils ne relient les dossiers aux personnes en particulier. Quelque part dans votre base de données (ou dans l'application elle-même), vous aurez à faire la relation entre l'utilisateur et les éléments. Si quelqu'un a accès, ils auront accès à ce mécanisme.

Il n'y a absolument aucun moyen d'empêcher cela.

La réalité est que, en ayant un accès complet, nous sommes en mesure de confiance. Cela signifie que les chefs d'entreprise doivent faire confiance que même si vous pouvez voir les données, vous n'agir de quelque façon que sur elle. C'est là de petites choses comme l'éthique entrent en jeu.

Maintenant, cela dit, beaucoup de sociétés distinctes le développement et le personnel de production. Le but est d'éliminer le développement d'avoir un contact direct avec en direct (par exemple: réel) des données. Cela a un certain nombre d'avantages avec la sécurité et la fiabilité des données se trouvant au sommet du tas.

Le seul inconvénient est que certains Les développeurs pensent qu'ils ne peuvent pas résoudre un problème sans accès à la production. Toutefois, cela est tout simplement pas vrai.

Le personnel de production serait alors les seuls à avoir accès aux serveurs live. Ils seront généralement à un degré sélectionnés plus grand (antécédents criminels et autres vérifications des antécédents) qui est compatir avec le type de données que vous devez protéger.

Le point de tout cela est que cela est un problème de personnel; et non celui qui peut vraiment être résolu avec des moyens techniques.

UPDATE

D'autres semblent ici manquer un morceau très important et vital du puzzle. À savoir que les données sont entrées dans le système pour une raison. Cette raison est presque universellement pour qu'il puisse être partagé. Dans le cas d'un rapport de dépenses, que les données sont saisies afin que la comptabilité peut savoir qui rembourseront.

Ce qui signifie que le système, à un certain niveau, devra correspondre aux utilisateurs et des objets sans la personne saisie des données. (Ex: un vendeur) étant connecté

Et parce que les données doivent être liées ensemble sans toutes les parties concernées debout à taper dans un code de sécurité pour « libérer » les données, puis un DBA sera absolument en mesure d'examiner les journaux de requêtes pour savoir qui est qui. Et je pourrais très facilement ajouter, peu importe combien de marques de hachage que vous voulez y jeter. Triple DES ne vous sauveront pas non plus.

A la fin de la journée, tout ce que vous avez fait est de rendre plus difficile le développement absolument aucun avantage de la sécurité. Je ne peux pas insister assez sur ce: le seul moyen de données cacher d'un dba serait soit pour 1. que les données à uniquement accessible par la personne même qui est entré ou 2. à ne pas existe en premier lieu.

En ce qui concerne l'option 1, si la seule personne qui peut jamais y accéder est la personne qui y est entré .. bien, il n'y a pas de point pour qu'il soit dans une base de données d'entreprise.

Autres conseils

Je crains que si votre application peut lier une personne à ses données, tout développeur peut / admin.

La seule chose que vous pouvez faire est ce qui rend plus difficile à faire le lien, pour ralentir le développeur / admin, mais si vous le rendre plus difficile pour les utilisateurs de lien vers les données, vous rendre plus difficile pour votre serveur aussi.

Idée basée sur @no idée:

Vous pouvez avoir un utilisateur classique / mot de passe de connexion à votre application (mot de passe haché, ou autre), et un spécial « pass » utilisé pour protéger vos données. Ce « pass » ne serait pas stocké dans la base de données.

Lorsque votre journal client dans votre application je dois fournir utilisateur / mot de passe / passe. L'utilisateur / mot de passe est vérifié avec la base de données, et le laissez-passer serait utilisé pour les données de charge / écriture.

Lorsque vous avez besoin des données d'écriture, vous faites un hachage de votre « nom d'utilisateur / pass » couple, et la stocker comme une clé reliant votre client à vos données.

Lorsque vous devez charger des données, vous faites un hachage de votre « nom d'utilisateur / pass » couple et charger toutes les données correspondant à ce hachage.

De cette façon, il est impossible de faire un lien entre vos données et votre utilisateur.

Dans une autre main, (comme je l'ai dit dans un commentaire à @no) Méfiez-vous des collisions . De plus, si « passer » votre écriture utilisateur un mauvais vous ne pouvez pas le vérifier.

Mise à jour:. Pour la dernière partie, j'ai eu une autre idée, vous pouvez stocker dans votre base de données un hachage de votre « pass / mot de passe » couple, de cette façon vous pouvez vérifier si votre « pass » est correct

Créer une table avec les utilisateurs:
1. user_id: une colonne d'identité (id auto-généré)
2. nom d'utilisateur
3. Mot de passe: assurez-vous qu'il est haché
Créer une table de produits comme dans votre exemple:
1. user_hash
2. élément
3. prix

Le user_hash sera basé sur des user_id qui ne change jamais. Nom d'utilisateur et mot de passe sont libres de changer au besoin. Lorsque l'utilisateur se connecte, vous comparer le nom d'utilisateur / mot de passe pour obtenir le user_id. Vous pouvez envoyer le dos de user_hash au client pendant toute la durée de la session, ou une version cryptée / indirecte du hachage (peut-être un ID de session, où le serveur stocke les user_hash dans la session).

Maintenant, vous avez besoin d'un moyen de hachage de la user_id dans user_hash et de les protéger.

Si vous le faites côté client comme suggéré @no, le client doit avoir user_id. Gros trou de sécurité (surtout si elle est une application web), hachage peut être facilement trafiqué et algorithme est librement accessible au public.
Vous pourriez avoir en fonction de la base de données. Mauvaise idée, puisque la base de données a tous les éléments pour relier les dossiers.
Pour les applications des sites Web ou client / serveur que vous pourriez avoir sur votre code côté serveur. Beaucoup mieux, mais un développeur a accès à l'algorithme de hachage et des données.
Avoir une autre écriture de développeur l'algorithme de hachage (que vous n'avez pas accès) et le bâton sur un autre serveur (que vous pouvez aussi ne pas avoir accès) en tant que service TCP / web. Votre code côté serveur alors passer l'ID utilisateur et obtenir un retour de hachage. Vous auriez pas l'algorithme, mais vous pouvez envoyer tous les ID utilisateur par le biais d'obtenir toutes leurs hash dos. Pas beaucoup d'avantages à # 3, bien que le service pourrait avoir l'exploitation forestière et ce pour essayer de minimiser le risque.
Si c'est tout simplement une application base de données client, vous avez seulement des choix # 1 et 2. Je suggère fortement d'ajouter une autre couche [d'entreprise] qui est côté serveur, distinct du serveur de base de données.

Edit: Cela chevauche quelques-uns des points précédents. Avoir 3 serveurs:

serveur d'authentification : Un employé a accès. Maintient table utilisateur. Dispose d'un service Web (avec des communications cryptées) qui prend la combinaison utilisateur / mot de passe. mot de passe Hashes, regarde user_id dans le tableau, génère user_hash. De cette façon, vous ne pouvez pas simplement envoyer tous user_ids et récupérer les hash. Vous devez avoir le mot de passe qui est pas stocké et est uniquement disponible au cours du processus d'authentification.
serveur de base de données principale : Employé B a accès. Seuls les magasins user_hash. Pas userid, aucun mot de passe. Vous pouvez lier les données à l'aide du user_hash, mais les informations de l'utilisateur réel est un autre endroit.
serveur site : Employé B a accès. Obtient informations de connexion, transmet au serveur d'authentification, récupère hachage, dispose alors d'informations de connexion. Conserve hachage en session pour l'écriture / l'interrogation de la base de données.

A employé a id_utilisateur, nom d'utilisateur, mot de passe et de l'algorithme. B employé a user_hash et des données. À moins modifie B employé le site pour stocker l'utilisateur brut / mot de passe, il n'a aucun moyen de relier les utilisateurs réels.

Utilisation de profils SQL, l'employé A obtiendrait user_id, nom d'utilisateur et mot de passe hachage (depuis user_hash est généré plus tard dans le code). B employé obtiendrait user_hash et des données.

La seule façon de faire en sorte que les données ne peuvent être connectés à la personne, il appartient est de ne pas enregistrer les informations d'identité en premier lieu (tout dépersonnalisera). Faire cela, cependant, serait très probablement rendre votre inutile l'application. Vous pouvez le rendre plus difficile à faire, mais vous ne pouvez pas le rendre impossible.

Le stockage des données de l'utilisateur et des informations d'identification dans les bases de données distinctes (et peut-être sur des serveurs distincts) et reliant les deux avec un numéro d'identification est probablement la chose la plus proche que vous pouvez faire. De cette façon, vous avez isolé les deux ensembles de données, autant que possible. Vous devez toujours conserver ce numéro d'identification en tant que lien entre eux; sinon, vous seriez incapable de récupérer les données d'un utilisateur.

En outre, je recommande de ne pas utiliser un mot de passe comme identifiant haché unique. Lorsqu'un utilisateur change son mot de passe, il vous faudra alors passer par et mettre à jour toutes vos bases de données pour remplacer les anciens ID de mot de passe haché avec les nouveaux. Il est généralement plus facile d'utiliser un identifiant unique qui ne repose pas sur l'une des informations de l'utilisateur (pour aider à veiller à ce qu'il reste statique).

Cela finit par être un problème social, pas un problème technologique. Les meilleures solutions seront une solution sociale. Après le durcissement de vos systèmes de protection contre l'accès non autorisé (pirates, etc), vous obtiendrez probablement un meilleur kilométrage travailler à établir la confiance avec vos utilisateurs et mettre en œuvre un système de politiques et de procédures relatives à la sécurité des données. Inclure des sanctions spécifiques pour les employés qui abusent de l'information à la clientèle. Depuis une seule violation de la confiance des clients est suffisant pour ruiner votre réputation et conduire tous vos utilisateurs loin, la tentation d'avoir abusé de ces données par ceux qui ont un accès « haut niveau » est moins que vous pourriez penser (depuis l'effondrement de la société en général l'emporte sur tout gain).

Gardez à l'esprit que même sans enregistrer réellement identifier la part de l'information de la personne, associant simplement assez d'informations tous avec la même clé pourrait vous permettre de comprendre l'identité de la personne associée à certaines informations. Pour un exemple simple, vous pouvez appeler le strip club et demander à quel client a conduit une Ferrari.

Pour cette raison, lorsque vous dépersonnaliser les dossiers médicaux (pour une utilisation dans la recherche et autres), vous devez enlever les anniversaires pour les personnes de plus de 89 ans (parce que les gens ce vieux sont assez rares qu'une date de naissance spécifique pourrait pointer vers un personne seule) et de supprimer le codage de tout changement géographique qui indique une zone contenant moins de 20.000 personnes. (Voir http://privacy.med.miami.edu/glossary/xd_deidentified_health_info.htm )

AOL a découvert la dure quand ils ont sorti la recherche des données que les gens peuvent être identifiés simplement en sachant ce que les recherches sont associées à une personne anonyme. (Voir http://www.fi. muni.cz/kd/events/cikhaj-2007-jan/slides/kumpost.pdf )

Il semble que vous avez raison sur la bonne voie avec cela, mais vous êtes un peu plus de penser (ou je ne comprends pas tout simplement)

Ecrire une fonction qui construit une nouvelle chaîne basée sur l'entrée (qui sera leur nom d'utilisateur ou quelque chose d'autre que les heures supplémentaires ne peux pas de changement)

Utilisez la chaîne retournée sous forme de sel lors de la construction du hachage utilisateur (encore une fois j'utiliser l'ID utilisateur ou nom d'utilisateur comme entrée pour le constructeur de hachage, car ils l'habitude changent comme mot de passe ou par courrier électronique des utilisateurs)

Associer toutes les actions de l'utilisateur avec le hachage utilisateur.

Pas une avec accès uniquement de base de données peut déterminer ce que l'enfer l'utilisateur hash moyenne. Même une tentative de forcer brute en essayant de semences différentes, des combinaisons de sel finira inutile parce que le sel est déterminée comme une variante du nom d'utilisateur.

Je pense que vous vous avez répondu propre question avec votre message initial.

En fait, il y a une façon que vous pourriez faire ce que vous parlez ...

Vous pourriez avoir l'utilisateur de type son nom et son mot de passe dans une forme qui exécute un script purement côté client qui génère un hachage basé sur le nom et pw. Ce hachage est utilisé comme identifiant unique pour l'utilisateur, et est envoyé au serveur. De cette façon, le serveur ne connaît que l'utilisateur par hachage, et non par nom.

Pour que cela fonctionne, cependant, le hachage devrait être différent du hachage de mot de passe normale, et l'utilisateur sera nécessaire pour entrer leur nom / mot de passe un temps supplémentaire avant que le serveur aurait une « mémoire » de ce que personne a acheté.

Le serveur pouvait se rappeler ce que la personne a acheté pour la durée de leur session et ensuite « oublier », parce que la base de données contiendrait aucun lien entre les comptes utilisateur et les informations sensibles.

modifier

En réponse à ceux qui disent hachant sur le client est un risque de sécurité: Il est pas si vous le faites correctement. Il faut supposer qu'un algorithme de hachage est connu ou connaissable. Dire montants par ailleurs à la « sécurité par l'obscurité. » Hash ne comporte pas de clés privées et hash dynamique pourrait être utilisé pour empêcher toute manipulation.

Par exemple, vous prenez un générateur de hachage comme ceci:

http://baagoe.com/en/RandomMusings/javascript/Mash.js

// From http://baagoe.com/en/RandomMusings/javascript/
// Johannes Baagoe <baagoe@baagoe.com>, 2010
function Mash() {
  var n = 0xefc8249d;

  var mash = function(data) {
    data = data.toString();
    for (var i = 0; i < data.length; i++) {
      n += data.charCodeAt(i);
      var h = 0.02519603282416938 * n;
      n = h >>> 0;
      h -= n;
      h *= n;
      n = h >>> 0;
      h -= n;
      n += h * 0x100000000; // 2^32
    }
    return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
  };

  mash.version = 'Mash 0.9';
  return mash;
}

Voyez comment les changements de n, chaque fois que vous hachez une chaîne vous obtenez quelque chose de différent.

Hash le nom d'utilisateur + mot de passe en utilisant un algo de hachage normale. Ce sera la même que la clé de la table « secret » dans la base de données, mais rien ne correspond d'autre dans la base de données.
Append la passe au nom d'utilisateur haché et hachage avec l'algorithme ci-dessus.
Base-16 encode var n et append dans le hachage d'origine avec un caractère délimiteur.

Cela va créer un hash unique (sera différent à chaque fois) qui peut être vérifié par le système contre chaque colonne dans la base de données. Le système peut être configuré être permettre à un hachage particulier unique, une seule fois (par exemple, une fois par an), ce qui empêche les attaques MITM, et aucune des informations de l'utilisateur est passé à travers le fil. À moins que je manque quelque chose, il n'y a rien d'insécurité à ce sujet.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow