Je pense que cet article peut être très pertinent pour ce que vous faites. Si en effet vous souhaitez "anonymiser" les SSN pour des raisons de sécurité et de responsabilité légale, le simple fait de les hacher ne suffit pas.
Le simple fait de les hacher serait un processus complètement déterministe, donc pour "masquer" efficacement les SSN individuels, le processus doit être randomisé. Sinon, vous pouvez simplement forcer brutalement toutes les combinaisons possibles de SSN (ce qui nécessiterait beaucoup moins de travail que d'essayer de forcer brutalement la fonction de hachage) et rechercher une valeur correspondante.
Pour voir pourquoi cela tient, prenons l'exemple le plus simpliste qu'un SSN pourrait simplement prendre deux valeurs, 0 et 1. Indépendamment de la qualité et de la force de la fonction de hachage, à la fin, il n'y aura que deux résultats possibles et c'est facile à voir qui est quoi.
C'est le vieux jeu de pourquoi vous ne devriez pas hacher, par exemple. mots de passe directement sans effectuer de prétraitement sur eux au préalable. Les données sous-jacentes ne contiennent tout simplement pas assez d'entropie et seront donc une cible facile pour les recherches dans une table précalculée.
Dès que vos SSN deviennent privés et confidentiels (ils ne sont pas dans tous les pays, alors pardonnez ma question stupide dans les commentaires :), les mêmes bonnes pratiques qui sont également utilisées pour le stockage des mots de passe devraient également s'appliquer à votre cas particulier, c'est-à-dire un ralentissement algorithme de hachage adaptatif qui compense le manque d'entropie initiale comme bcrypt, scrypt et PBKDF2 (qui était déjà recommandé par Marcus Adams).
