En général, c'est le cryptage moyen est censé fonctionner. Il est parfois appelé "ciphertext indistinguishability." L'affichage du même texte chiffré à chaque fois qu'un texte en clair donné est chiffré nuit à la sécurité en permettant aux pirates d'analyser les collections de texte chiffré à la recherche de modèles.
Dans ce cas, il semble que vous ne stockez qu'une seule instance du numéro de compte chiffré; vous pourriez argumenter que parce que le "message" n'est jamais répété, l'indiscernabilité du texte chiffré est discutable. Cela pourrait vous conduire à justifier l'utilisation du mode ECB (si votre API le propose) ou d'un HMAC (code d'authentification de message, proposé par la méthode hashData()) pour calculer une clé de recherche. Si un attaquant accède à votre base de données, il n'y aura qu'une seule instance de chaque clé, et rien ne sera révélé.
Cependant, ce n'est pas encore sûr si un attaquant peut fournir des numéros de compte que votre système crypte. Par exemple, un attaquant pourrait poser un utilisateur légitime et fournir un SSN lors de l'enregistrement. S'ils choisissent un numéro en double, puis regardent dans la base de données, leur valeur cryptée choisie de manière malveillante correspondra à un enregistrement légitime. Ou, si le système rejette leur numéro de compte parce qu'il s'agit d'un doublon, l'attaquant saura qu'il s'agit d'un numéro utilisé par un utilisateur légitime. Si vous utilisez un HMAC (ou un cryptage en mode ECB), vous devrez concevoir votre application très soigneusement pour éviter les attaques de texte en clair et d'oracle choisies. Et, franchement, si vous rencontrez ces idées pour la première fois, il y a probablement beaucoup d'autres lacunes dans vos connaissances qui mèneront à des vulnérabilités facilement exploitables dans votre application.
Merci beaucoup (O) – Tahir