Comment un système peut-il appliquer un nombre minimum de caractères modifiés dans les mots de passe, sans stocker ou traiter d'anciens mots de passe en texte clair?
Dans certains environnements, il est nécessaire que les utilisateurs modifient un certain nombre de caractères chaque fois qu'ils créent un nouveau mot de passe. Il s'agit bien sûr d'empêcher les mots de passe d'être facilement devinables, en particulier avec la connaissance d'anciens mots de passe tels qu'un employé décédé pourrait avoir un compte de service partagé.
J'ai séparéquestions ouvert pour aborder le côté poussant le bouton de cette application. Cependant, je suis également curieux de savoir comment cette application fonctionne sur le back-end. Si un mot de passe en texte clair ne peut pas être dérivé d'un algorithme de hachage fort, comment le système détermine-t-il combien de caractères ont été modifiés dans les nouveaux mots de passe?
Je ne suis pas sûr de comparer avec tous les mots de passe que l'utilisateur a déjà utilisés, car cela dépend vraiment du système de hachage que vous utilisez et je dirais que si c'est possible de dériver une similitude du hachage, ce n'est pas un très bon système pour commencer avec.
Mais en supposant que l'utilisateur doive fournir son mot de passe actuel lors de la définition de son nouveau mot de passe, vous pouvez au moins comparer le nouveau avec le mot de passe actuel, car vous aurez tous les deux un hachage à ce stade.
Le pam_cracklib le module sous Linux vérifie les mots de passe comme celui-ci et effectue quelques vérifications de base par défaut.
- Le nouveau mot de passe est-il juste l'ancien mot de passe avec les lettres inversées ("mot de passe" vs "drowssap") ou tourné ("mot de passe" vs "asswordp")?
- Le nouveau mot de passe diffère-t-il uniquement de l'ancien en raison d'un changement de casse ("mot de passe" vs "mot de passe")?
- Y a-t-il au moins un nombre minimum de caractères dans le nouveau mot de passe qui ne figure pas dans l'ancien mot de passe? C'est là que le paramètre "difok" entre en jeu.
Vous pouvez trouver plus de détails à ce sujet ici .
Cela se fait facilement lors du changement de mot de passe (où l'utilisateur est et devrait être invité à fournir à la fois l'ancien et le nouveau mot de passe).
Habituellement, lorsque vous modifiez votre mot de passe, vous devez d'abord saisir l'ancien mot de passe. Ceci est utile pour la sécurité, pour garantir que quelqu'un qui passe près de votre ordinateur ne puisse pas changer très rapidement le mot de passe et vous verrouiller lorsque votre dos est tourné. Il permet également au serveur d'appliquer des règles de distance de mot de passe. Le serveur n'a besoin que de conserver l'ancien mot de passe en mémoire aussi longtemps qu'il le faut pour vérifier que le nouveau mot de passe est suffisamment différent de l'ancien. Il n'a jamais besoin de stocker le mot de passe non haché.
Soit dit en passant, ces règles de changement de mot de passe sont mauvaises pour la sécurité. (Oui, je sais que vous êtes la victime ici.) Si les utilisateurs doivent changer leur mot de passe souvent, ils choisiront un mot de passe très facile à retenir ou l'écriront dans un endroit facilement accessible. L'expiration des mots de passe présente peu d'avantages et la perte attendue de la force des mots de passe due au fait que les utilisateurs changent leur mot de passe tous les quelques mois de plus compense ces avantages. Pour un traitement plus approfondi de l'expiration des mots de passe, voir Comment le fait de changer votre mot de passe tous les 90 jours augmente-t-il la sécurité? et Forcer les utilisateurs à changer les mots de passe est-il utile? et Nécessite un changement de mot de passe régulier mais stocke les mots de passe précédents?
L'utilisateur doit entrer l'ancien et le nouveau mot de passe pour un changement de mot de passe. Il est donc facile de comparer le nouveau mot de passe à l'ancien, car la version en clair est fournie par l'utilisateur.
Pour comparer le nouveau mot de passe aux mots de passe précédents (autres que le mot de passe actuel), la vérification ne peut être effectuée qu'en comparant les résultats de hachage. Toute méthode qui permettrait toute autre comparaison serait une faille de sécurité.
Habituellement, lorsque vous modifiez votre mot de passe, vous devez d'abord saisir l'ancien mot de passe. Ceci est utile pour la sécurité, pour garantir que quelqu'un qui passe près de votre ordinateur ne puisse pas changer très rapidement le mot de passe et vous verrouiller lorsque votre dos est tourné. Il permet également au serveur d'appliquer des règles de distance de mot de passe. Le serveur n'a besoin que de conserver l'ancien mot de passe en mémoire aussi longtemps qu'il le faut pour vérifier que le nouveau mot de passe est suffisamment différent de l'ancien. Il n'a jamais besoin de stocker le mot de passe non haché et peut effacer l'ancien hachage dès qu'il a stocké le nouveau.
Si le serveur vérifie l'égalité avec les mots de passe plus anciens, et pas seulement avec le dernier, c'est une autre histoire. Il est assez facile de vérifier la réutilisation des mots de passe avec les anciens hachages: pour chaque ancien hachage, calculez le hachage du nouveau mot de passe avec l'ancien sel et comparez avec l'ancienne valeur de hachage. Sur un système correctement configuré, cela devrait prendre quelques secondes.
C'est une question différente si le serveur vérifie la similitude avec des mots de passe plus anciens, et pas seulement l'égalité avec des mots de passe plus anciens plus la similitude avec le précédent. Si le serveur utilise des hachages appropriés, il doit essayer des variantes du nouveau mot de passe et hacher chaque variante avec tous les anciens sels. Cela pourrait prendre quelques minutes ou plus avec un nombre non négligeable de variations. Donc, si le serveur se plaint de similitude avec un mot de passe plus ancien, je me méfierais qu'ils stockent peut-être des mots de passe mal hachés.
Il existe une autre approche pour la similitude, qui consiste à stocker le hachage de chaque variante de mot de passe, chacun indépendamment salé, dès que le mot de passe est défini. Mais cela ne vous rapporte pas grand-chose: le serveur doit toujours calculer le hachage du nouveau mot de passe avec tous ces sels, ce qui prend encore beaucoup de temps, trop de temps pour un changement de mot de passe typique.
Un moyen de récupérer d'anciens mots de passe qui fonctionne réellement, mais que je n'ai jamais vu implémenté nulle part, consiste à effectuer les opérations suivantes lors d'un changement de mot de passe, après avoir demandé à l'utilisateur l'ancien mot de passe et avant d'effacer l'ancien mot de passe de la mémoire:
- Dérivez une clé symétrique du nouveau mot de passe (en utilisant un algorithme de renforcement de clé).
- Dérivez une clé de l'ancien mot de passe de la même manière.
- Déchiffrez la liste des anciens mots de passe avec l'ancienne clé.
- Ajoutez l'ancien mot de passe à la liste.
- Vérifiez les règles - tous les mots de passe antérieurs sont connus à ce stade. Si le nouveau mot de passe passe les contrôles…
- Chiffrez la liste des anciens mots de passe avec la nouvelle clé.
- Modifiez le mot de passe et la liste cryptée des mots de passe antérieurs de la base de données.
Ceci est quelque peu risqué car si le mot de passe actuel est compromis, tous les mots de passe antérieurs sont également exposés. Mais cela permet d'appliquer une politique de distance de mot de passe à n'importe quel nombre de mots de passe antérieurs avec un effort de calcul raisonnable.
Cela ne peut se faire qu'en gardant des hachages, cela peut même se faire sur plusieurs itérations.
La méthode serait de prendre le mot de passe et de le parcourir à travers l'algo de hachage et de vérifier les comparaisons avec les valeurs stockées.
Par exemple, la plupart des utilisateurs (et les gens du service d'assistance adorent y recourir en dernier recours avec des types importants en colère) répéteront leurs mots de passe de manière incroyablement simple.
Donc, prendre le mot de passe: # foob @ r1 et le rendre # foob @ r2 que vous êtes susceptible de voir peut être testé à l'insu de # foob @ r1 en exécutant rapidement une force brute sur l'algo. Avec une puissance de traitement moderne, vous pouvez parcourir les 4 premiers caractères en moins de dix secondes.
Bien que pour des raisons d'efficacité, les quatre derniers sont généralement ceux que les gens changent, vous êtes donc susceptible de voir plus pour votre argent là-bas. Si vous allez faire non consécutif et consécutif, vous envisagez une assez grande attente pour l'utilisateur final et un gros morceau de processeur.