Aujourd'hui, nous verrons comment stocker au mieux les mots de passe dans une base de données et comment les plates-formes connues résolvent ce problème.
Plaintext
Lorsque la question s'est posée de stocker les mots de passe, bien sûr, la première idée a été de simplement les écrire ouverts dans la plaque signalétique appropriée dans la base de données. Et tout irait bien si les clients ne pouvaient pas vraiment y accéder directement. Mais, malheureusement, une telle injection SQL bien connue fonctionne parfois encore dans diverses applications Web, sans parler d'autres vulnérabilités potentielles. En matière de sécurité, il est généralement admis d'assumer le pire et de préparer un plan d'action et de protection même dans un tel cas. Nous supposons qu'un attaquant a trouvé une faille dans une application Web, d'une manière ou d'une autre, décharge joyeusement une table avec des noms d'utilisateur et des mots de passe, puis les supprime à sa guise. En général, ses autres actions peuvent être les suivantes:
- effectuer des actions illégitimes au nom des utilisateurs en utilisant leurs informations d'identification sur une ressource vulnérable: par exemple, une carte bancaire est liée à un compte, et maintenant un attaquant peut l'utiliser;
- une tentative d'utiliser le mot de passe reçu sur d'autres ressources: loin d'être toujours, les utilisateurs, suivant les conseils, trouvent à chaque fois de nouveaux mots de passe pour différents services;
- une tentative d'identifier la règle pour générer un mot de passe et aller au deuxième point: certains forment une règle pour générer un mot de passe, en conséquence, les mots de passe sur différentes ressources sont différents, mais ils obéissent à la même règle qui peut être détectée;
- élévation de privilèges: le mot de passe administrateur peut également être stocké dans la même table, avec la connaissance de laquelle vous pouvez parfois obtenir un contrôle total sur le serveur.
Hachage de chiffrement
L'idée s'avère tout de suite moins bonne. Que faire Ce serait formidable de stocker les mots de passe sous forme cryptée. Ensuite, même s'ils sont supprimés, ils ne pourront pas récupérer, ou du moins ils y passeront trop de temps. Ici, le choix se fait entre deux branches de développement: chiffrer les mots de passe ou hacher. Les développeurs se sont installés sur le second, et, en principe, il est clair pourquoi. Comparez nos candidats pour différentes caractéristiques:
- Intrant travail. Le chiffrement prend plus de temps, et quelle que soit la conversion que nous choisissons, elle devra être effectuée à chaque vérification du mot de passe. L'une des exigences pour les fonctions de hachage est la vitesse d'exécution.
- La longueur des valeurs de sortie. Le résultat du chiffrement est de longueur variable, le résultat du hachage est toujours le même et le stockage de données uniformes dans une base de données est très pratique. Sans oublier le fait que la longueur du mot de passe sous forme cryptée donnera quelques informations sur la longueur du mot de passe d'origine. La même longueur, cependant, conduit à la possibilité de collisions, mais plus sur celle ci-dessous.
- Gestion des clés. Le cryptage nécessite une clé, qui devra également être stockée quelque part et espérons que personne ne la trouvera. Dans tous les cas, la génération et la gestion des clés est une histoire distincte (elles ne doivent pas être faibles, elles doivent être modifiées régulièrement, etc.).
- La possibilité d'un conflit. Lors du cryptage, la sortie de différentes données d'entrée sera toujours également différente. Avec le hachage, ce n'est pas toujours le cas. Une longueur de hachage constante signifie que l'ensemble des valeurs de sortie de la fonction de hachage est limité, ce qui peut entraîner une collision. Autrement dit, supposons que l'utilisateur soit vraiment confus et ait trouvé un mot de passe long vraiment cool, qui a des caractères spéciaux, des chiffres et des lettres en minuscules et en majuscules. L'attaquant entre le mot de passe non moins cool «admin» dans le champ du mot de passe. Le serveur l'a haché pour vérifier et comparer les hachages. Hashs assortis. C'est dommage.
Ainsi, avec un score de 3: 1, le hachage gagne. Mais est-il possible de s'arrêter là?
La réponse est non.
Attaques par mot de passe haché
Ainsi, l'attaquant a obtenu notre table avec des noms d'utilisateur et des mots de passe. Les mots de passe sont désormais hachés, mais cela n'arrête pas notre attaquant, et il compte sérieusement les récupérer. Ses actions possibles:
- dictionnaire bruteforce: si l'attaquant n'a pas réussi avec le mot de passe de référence de l'administrateur, il se tournera vers le dictionnaire des mots de passe populaires et tentera sa chance avec leurs hachages;
- tables arc-en-ciel: en général aujourd'hui, il n'aura peut-être pas besoin de calculer quoi que ce soit et de trier le dictionnaire. Il suffira de se tourner vers les tables arc-en-ciel allongées sur le réseau. Les tables arc-en-ciel contiennent des valeurs de hachage déjà calculées par quelqu'un avant et leurs données d'entrée correspondantes. Il est important de noter qu'en raison de collisions, le mot de passe que la table arc-en-ciel offrira ne sera pas nécessairement celui que l'utilisateur utilisera. Les valeurs calculées sont déjà pour MD5, SHA1, SHA256, SHA512, ainsi que pour leurs modifications et quelques autres. Vous pouvez essayer d'inverser le hachage, par exemple, ici ;
- recherche exhaustive: si cela ne vous aide pas, vous devrez recourir à la force brute et trier tous les mots de passe possibles d'affilée jusqu'à ce que les hachages calculés correspondent finalement.
Dans le cas le plus général, un attaquant devra casser des mots de passe. Et ici, son succès dépendra, entre autres, de la vitesse de calcul de la fonction de hachage. Une comparaison du temps de hachage peut être trouvée
ici . Par exemple, les fonctions de hachage implémentées Java sur Windows 10 64 bits avec 1 cœur Intel i7 2,60 GHz et 16 Go de RAM ont été exécutées un million de fois pour calculer un hachage de 36 caractères. Ils ont montré les résultats suivants:
MD5 - 627 ms
SHA-1 - 604 ms
SHA-256 - 739 ms
SHA-512 - 1056 ms
Mais aujourd'hui, bruteforce peut être parallélisé et exécuté plusieurs fois plus rapidement sur le GPU (ainsi que sur l'APU, le DSP et le FPGA). Cependant, en plus de choisir un algorithme plus long et une sortie plus longue, vous pouvez faire autre chose.
Hachage de hachage
Pour empêcher un attaquant d'utiliser des tables arc-en-ciel prêtes à l'emploi, il existe une technique pour hacher plusieurs fois un mot de passe. Autrement dit, nous calculons le hachage à partir du hachage à partir du hachage à partir du hachage ... et donc n fois (il est cependant nécessaire de ne pas trop s'impliquer avec cela, car lors de la vérification habituelle du mot de passe de l'utilisateur, le serveur devra également le faire). Maintenant, c'est si simple selon la table arc-en-ciel qu'il ne trouvera pas le mot de passe, et le temps pour la force brute augmentera considérablement. Mais rien n'empêchera l'attaquant de générer une table arc-en-ciel à partir du dictionnaire de mots de passe, connaissant l'algorithme de hachage. De plus, pour les combinaisons les plus populaires de cette méthode, de telles tables ont déjà été générées:
"
Ajouter du sel au goût
Pour qu'il ne puisse pas faire cela, les mots de passe sont hachés aujourd'hui avec l'ajout de sel.
Un sel est une chaîne aléatoire supplémentaire qui est affectée à un mot de passe et hachée avec lui. Vous ne pouvez pas récupérer le mot de passe du hachage ainsi obtenu de la table arc-en-ciel. Connaissant le sel et le hachage de sortie, l'attaquant est voué à la force brute et aucune table pré-calculée ne l'aidera probablement.
Taxonomie de salage de mot de passe:
1. Selon le principe du salage:
- un sel unique pour chaque utilisateur: individuel pour chaque utilisateur - de cette façon, si le sel devient connu de l'attaquant, chaque mot de passe devra être bruté. Et d'ailleurs, même si deux utilisateurs pensent de la même façon et proposent des mots de passe identiques, les hachages seront toujours différents dans la sortie;
- sel global: le même pour tous, utilisé pour tous les hachages;
- à la fois cela et un autre.
2. Selon la méthode de stockage du sel:
- dans la base de données: en règle générale, les sels individuels sont stockés dans la même base de données que les hachages de mot de passe; souvent même sur la même ligne;
- dans le code (lire: dans la config): le sel global n'est généralement pas stocké dans la base de données, mais, par exemple, dans la config, de sorte que le contrevenant devrait consacrer du temps à sa sélection.
Nous supposons que les sels d'utilisateurs individuels sont stockés dans la base de données, le sel global dans la configuration. L'attaquant a accédé à la base de données, et il connaît tous les hachages et leurs sels correspondants (le sel global n'est pas stocké dans la base de données, et il ne le sait pas). Au total, si toutes les méthodes sont combinées, afin d'obtenir des mots de passe sous une forme claire, comme c'était le cas dans les premiers systèmes, lui, étant extrêmement déterminé, rencontrera les obstacles suivants:
- Il ne connaît pas le sel mondial, il devra donc être brutalisé.
- Il connaît les sels des utilisateurs, mais il n'a pas préparé de tableaux avec ces sels, il devra donc casser les mots de passe.
- Ce processus prendra encore plus de temps car vous devez hacher n fois.
Comment les mots de passe stockent-ils divers CMS
Wordpress
Avant la version 3.x, les mots de passe étaient simplement hachés avec MD5. Maintenant, la bibliothèque phpass est utilisée. Par défaut, salt est affecté au mot de passe en face et la chaîne résultante est hachée MD5 2 ^ 8 fois.
Joomla
Avant la version 1.0.12, seul MD5 était utilisé. La bibliothèque phpass est utilisée, par défaut bcrypt avec salt et 2 ^ 10 répétitions.
Drupal
Jusqu'à la version 6 md5 sans sel. La bibliothèque phpass est utilisée. La valeur par défaut est sha512 salé avec 2 ^ 16 répétitions.
Silverstripe
Utilise Blowfish salé avec 2 ^ 10 répétitions.
Umbraco
Utilise HMACSHA256 avec du sel. Utilise le deuxième sel global spécifié dans la configuration.