Est-il possible de stocker en toute sécurité des mots de passe en utilisant un cryptage réversible?
Tout le monde dit que vous devez utiliser un hachage non réversible lorsque vous stockez des mots de passe afin que, même en cas de fuite de votre base de données, les mots de passe eux-mêmes soient toujours sûrs. Je me demande s'il existe de toute façon un cryptage réversible pour stocker les mots de passe.
À tout le moins, vous devrez exiger que tout exploit qui fuit la base de données (injection SQL, accès au serveur Shell, etc.) ne fuit pas la clé de chiffrement et qu'il ne serait pas raisonnablement possible de comprendre la clé de chiffrement à l'aide de un mot de passe en clair connu si vous avez la fuite de la base de données.
Je n'envisage pas sérieusement de faire cela car il semble que même si c'est techniquement possible, ce serait difficile à faire correctement, mais cela semble être un problème intéressant.
Le cryptage réversible n'est pas couramment utilisé pour les mots de passe car les exigences et paramètres spécifiques de l'authentification par mot de passe sont incompatibles avec la faiblesse du cryptage réversible.
La principale faiblesse du chiffrement réversible est simple: si la clé est compromise, les données chiffrées sont compromises, point final.
Les mots de passe sont utilisés tout le temps, chaque fois que les utilisateurs se connectent. Par conséquent, le processus d'authentification doit pouvoir accéder aux informations d'identification des utilisateurs à tout moment, de manière automatisée, sans contrôles obstructifs. Cela signifie que la clé du chiffrement réversible doit être sur le disque ou en mémoire tout le temps. Si ce programme, ce disque ou cette mémoire sont en quelque sorte compromis, alors tous ces mots de passe cryptés réversibles sont tous compromis d'un seul coup.
En revanche, envisagez l'utilisation de hachages non réversibles. Si le programme, le disque ou la mémoire sont compromis, l'attaquant obtient les hachages "verrouillés" et il n'y a pas de clé. Ils peuvent alors attaquer plus loin - attaque de texte chiffré connue, force brute, etc. - mais ils n'ont pas encore "gagné".
Nous utilisons tout le temps un cryptage réversible (laissez-moi saisir) - disques, fichiers, pièces jointes aux e-mails. Ce que ces utilisations ont en commun, cependant, c'est qu'elles encouragent (sinon nécessitent) l'intervention humaine pour fournir la clé.
Je ne sais pas pourquoi vous posez cette question, mais qu'en est-il d'un modèle hybride? Considérez qu'il peut être raisonnable de stocker les deux texte chiffré réversible et non réversible pour les mots de passe des utilisateurs. Lorsque les mots de passe sont créés, stockez deux versions chiffrées: l'une créée avec une fonction de hachage unidirectionnelle et l'autre créée avec un algorithme de chiffrement asymétrique ("cryptographie à clé publique"). Tous les processus d'authentification automatisés utilisent les hachages non réversibles à des fins d'authentification. Gardez la moitié de la "clé publique" de la paire sur le système pour pouvoir générer les mots de passe chiffrés et stockez la moitié de la "clé privée" de la paire hors ligne . Si le texte en clair du mot de passe est nécessaire, mettez le mot de passe chiffré hors ligne et déchiffrez-le avec la clé appropriée. Tant que la clé de déchiffrement n'est pas accessible au système d'authentification, un attaquant ne peut pas profiter du fait que vous avez utilisé un chiffrement "réversible" pour stocker des mots de passe en texte brut.
Cela ne vous aidera que si votre besoin d'accéder aux mots de passe en clair n'est pas un besoin automatisé, bien sûr. Mais cela me semble une idée astucieuse.
Est-il possible de stocker en toute sécurité des mots de passe en utilisant un cryptage réversible?
Oui, mais c'est beaucoup plus difficile et nécessite des efforts et des dépenses beaucoup plus importants. La saisie est difficile à bien faire.
Afin de prendre en charge le cryptage réversible (pas nécessairement symétrique comme le note @goenfawr ), vous avez besoin d'au moins une clé (deux pour la cryptographie à clé publique). Vous devez générer la clé, la stocker en toute sécurité, la protéger de la corruption ou de la destruction, la récupérer pour l'utiliser, la protéger lorsqu'elle est en cours d'utilisation et la remplacer périodiquement.
Une partie importante du problème est de savoir comment protéger la clé lorsqu'elle n'est pas utilisée. Si vous cryptez la clé, vous avez besoin d'une autre clé pour la décrypter. Dans ce cas, vous êtes de retour là où vous avez commencé. D'autres méthodes de protection utilisent du matériel spécial, des systèmes d'exploitation sécurisés ou même des ordinateurs personnalisés avec une mémoire et des processeurs séparés pour les paramètres de sécurité. Toutes ces solutions nécessitent des coûts de formation et d'assistance supplémentaires.
Comparez ces solutions à l'utilisation d'un ordinateur de vente au détail, d'un système d'exploitation de vente au détail et d'une fonction de hachage.
Une chose à ajouter aux réponses existantes, c'est qu'il est possible d'utiliser un cryptage symétrique (réversible) pour stocker des secrets (y compris les mots de passe) mais c'est un peu plus complexe/cher.
Un bon exemple de cela est les réseaux de distributeurs automatiques de billets/distributeurs automatiques de billets, qui utilisaient traditionnellement la gestion symétrique des clés (bien qu'ils la déplacent vers une solution basée sur PKI).
La clé (sans jeu de mots) pour cela est que les clés de cryptage sont stockées dans un emplacement de confiance, dans ce cas, un module de sécurité matérielle (HSM) et des procédures strictes relatives au chargement et à la gestion des clés doivent être suivies, pour garantir que les clés restent secret.
Jetez un œil à la page wiki de Ciphers. Bien qu'il existe de nombreux chiffrements sécurisés, il existe toujours un risque de fuite de clé. L'utilisation d'un hachage unidirectionnel évite ce risque en n'ayant pas de clé.
Un principe d'ingénierie de la sécurité consiste à minimiser les informations pouvant être obtenues étant donné que le système est compromis.