hash pour identifier des utilisateurs

Bonjour à tous!

Je relance une veille discution mais qui m'intéresse beaucoup.

Chez un client, la CNIL préconise d'anonymiser les données (nom, prénom,date de naissance) avec la fonction de hachage SHA-1 avant de les insérer en base.
La clé permettant d'identifier un unique utilisateur est le nom, prénom et date de naissance. Du coup on fait des jointures entre différentes tables sur cette clé.

Je me suis renseigné un peu mais j'ai encore quelque doute.
Une chaine de caractère donnera toujours le même résultat si j'ai bien compris, mais deux chaines de caractères différentes peuvent aussi donner le même résultat. Du coup même si les chances sont extrêmement mince, on peut se retrouver avec des doublons, nan?
La question que je me pose, c'est de savoir si la probabilité d'avoir ces doublons sont tellement faible qu'on peut y aller les yeux fermés ou bien y a-t-il des risque?? (sachant que la base va contenir à terme 1 000 000 de lignes différents)

Pour passer du md5 en clair c'est relativement simple et rapide (voir ici)

Pour le sha1 à ma connaissance, ce n'est pas encore possible

plusieurs choses, et, comme préliminaire, en français on parle de chiffrement/déchiffrement le mot cryptage étant réservé à ceux qui ont perdu le mot de passe.

• premièrement l'opération de hachage est une opération irréversible, si elle ne l'est pas, c'est une mauvaise fonction de hachage
• la solution de "crakage" proposée ci dessus par mes pairs est une rainbow table, c'est donc une force brute améliorée: aucun algo de chiffrement ou de hashage n'est réputé non fiable lorsqu'il est attaqué avec succès par la force brute. Si vous ne me croyez pas, je vous met au défit de composer une rainbow table pour tout les mots de passes allant jusqu'à 10 caractères, spécialement pour la famille shaXXX.
• enfin côté base de donnée, faire une jointure sur un uid ou un pseudo uid est une extrême mauvaise idée. Utiliser une séquence (oracle) ou un auto-increment (mysql) pour générer une clé artificielle aura toujours de meilleur résultat. La démonstration est a portée de clics.
• au vu de la taille attendue de la base il est possible que tu aies des "doublons" de sha1, même si c'est assez improbable: je pense qu'il faudrait faire un calcul de probabilité pour mesurer le risque. Dans l'organisme ou je travaillais il y avait au moins 2 personnes de même nom et prénom (d'origine Française) sur un effectif de 2500 personnes. Je précise l'origine géographique du nom car dans certains pays les noms de familles sont très peu nombreux et la probabilité est donc accrue. (la caricature dit que la moitié des vietnamien s'appelle Nguyen). Dans mon cas la date de naissance était suffisante pour discriminer.
  Ce que tu peux faire c'est employer un numéro unique dans la chaine du sha1 comme une adresse mail ou un matricule: cependant il faut les avoir.
• un autre risque que tu cours, et que tu n'exprimes pas clairement, c'est trouver une collision entre deux empreintes, la probabilité existe, elle est facile à mesurer en postulant que sha1 est idéale est à une sortie absolument aléatoire, compare cette probabilité avec celle du point précédant.

Enfin je n'ai connaissance d'aucune collision md5 qui soit simultanément une collision sha1. J'ai connaissance d'un générateur de collision pour md5 (à partir du clair et non du haché) mais pas pour sha1 (ou sinon l'informatique a fait des progrès dans mon dos). Je suis sur que la probabilité est quantique tellement elle me parait faible. Même rapporté à un million de cas et sachant le phénomène du paradoxe des anniversaires...

Sinon tu peux aussi rajouter un grain de sel unique pour chaque compte dans ta table ce qui aura pour effet d'accroitre la sécurité et d'empecher justement les doublons parfaits (peux de chance qu'un doublons parfaits attrape le même grain de sel qu'un autre quand même...)

Ok merci pour les réponses, c'est deja beaucoup plus clair.
Je sais qu'une séquence serait plus juste mais je n'ai pas la main sur la base...

tu es dans une phase de dev probablement, hésite pas à faire des suggestions avant d'avoir des problèmes de performances, surtout pour la taille de la base visée.

1000000 de personnes uniques ça c'est un sacré fichier client !!!!