Le Art. 29 WP a publié l ' avis 05/2014 sur les techniques d'anonymisation. Là, il définit une fonction de hachage comme celle-ci:

Fonction de hachage: cela correspond à une fonction qui renvoie une sortie de taille fixe à partir d'une entrée de n'importe quelle taille (l'entrée peut être un seul attribut ou un ensemble d'attributs) et ne peut pas être inversé; cela signifie que le risque d'inversion vu avec le cryptage n'existe plus. Cependant, si la plage de valeurs d'entrée de la fonction de hachage est connue, elles peuvent être relues via la fonction de hachage afin de dériver la valeur correcte pour un enregistrement particulier. Par exemple, si un ensemble de données a été pseudonymisé en hachant le numéro d'identification national, cela peut être dérivé simplement en hachant toutes les valeurs d'entrée possibles et en comparant le résultat avec ces valeurs dans l'ensemble de données. Les fonctions de hachage sont généralement conçues pour être relativement rapides à calculer et sont sujettes à des attaques par force brute. Des tables précalculées peuvent également être créées pour permettre l'inversion en masse d'un grand ensemble de valeurs de hachage.

L'utilisation d'une fonction de hachage salé (où une valeur aléatoire, connue sous le nom de «sel», est ajouté à l'attribut en cours de hachage) peut réduire la probabilité de dériver la valeur d'entrée, mais néanmoins, le calcul de la valeur d'attribut d'origine cachée derrière le résultat d'une fonction de hachage salée peut toujours être faisable avec des moyens raisonnables.

Une fonction de hachage est donc considérée comme une pseudonymisation, pas une anonymisation. Les données pseudonymisées sont toujours des données personnelles. Voir également l ' article 4 du RGPD qui contient les définitions de «données personnelles» et de «pseudonymisation».

Dans votre question, vous dites que vous souhaitez donner aux utilisateurs la possibilité de conserver leur consentement plus longtemps. Vous utilisez donc un hachage pour identifier un tel utilisateur. Cela implique que vous êtes en mesure d'identifier un utilisateur, il s'agit donc de données personnelles. Cela ne signifie pas que votre traitement est illégal. Si vous indiquez clairement aux utilisateurs que vous enregistrez leur consentement lorsqu'ils sélectionnent cette option, ils consentent implicitement également à l'enregistrement lui-même, donc art. 6 (1) a) s'applique. Mais aussi l'art. 6 (1) (b) s'appliquerait probablement.

Art. 25 et Art. 32 encourager l'utilisation de la pseudonymisation lors du traitement des données personnelles.

Ce qui précède ne s'appliquerait que si la fonction de hachage génère un hachage unique pour chaque entrée. Si vous utilisez une fonction de hachage où différentes entrées génèrent le même hachage, cela ne sera pas considéré comme une agrégation (ou une généralisation). Art. 29 WP a également écrit à ce sujet dans son Avis 05/2014 sur les techniques d'anonymisation. Voir le sujet «Agrégation et K-anonymat» (3.2.1). Donc même l'agrégation ne permet pas une anonymisation efficace dans tous les cas.

Cela dépend si vous pouvez identifier la personne à laquelle appartient un hachage de nom d'utilisateur.

Si vous stockez à la fois le nom d'utilisateur et son hachage dans la même ligne de base de données, alors oui.

Si il est impossible pour vous d'identifier la personne uniquement par son hachage, alors non.

Cela vient de la définition des données personnelles - " toute information relative à un ou personne physique identifiable ", et Considérant 26: Non applicable aux données anonymes. Le hachage est essentiellement une donnée anonyme quand il ne permet pas à lui seul d'identifier la personne (avec des efforts raisonnables, c'est-à-dire sans dépenser $$$ en détectives ou en criminalistique).