Web : Stockage de mot de passe LOG619 Automne 2011 Olivier Bilodeau

Web : Stockage de mot de passe LOG619 Automne 2011 Olivier Bilodeau 1

Plan Historique du Web Problème du stockage de mots de passe La menace Le craquage de mots de passes Évolution d'une solution et ses problèmes Conclusion 2

Historique du Web - mot de passes Rappel: 3 façon de faire de l'authentification Quelque chose que l'on { sait, a, est } { a, est } requièrent: Accès sur un canal autre pour échapper au mitm (téléphone) Accès à la personne physique (biométrie) Infrastructures à clés publiques (PKI) Accès a des jetons matériels (hardware tokens) Qui sont: Trop coûteux pour la compagnie Peu commode Trop coûteux pour le client Conséquence: L'authentification sur le Web est basée sur quelque chose que l'on sait. => mot de passes 3

Le problème "The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts." -- CWE-257: Storing Passwords in a Recoverable Format Un attaquant peut attaquer une organisation à partir d'un mot de passe laissé par un utilisateur sur un autre site qui a été compromis et qui était vulnérable à CWE-257 Il est facile pour un employé administrateur mal intentionné d'utiliser l'accès de quelqu'un d'autre 4

Précision de la menace Passif vs actif Nous nous intéressons à un attaquant qui a obtenu accès au contenu de la base de données. Donc qui peut faire des attaques passives sans avoir a interagir avec la victime. Les attaques actives sur la session ou les mots de passe sont beaucoup plus complexe à réaliser car le site en question doit être rejoint ce qui fait qu'il peut décider de bloquer un compte ou un IP après plusieurs tentatives de connexion infructueuses. 5

Solution 0 - stocker en clair Compromettre la base de données équivaut à obtenir tous les mots de passe de tous les utilisateurs Usurper un utilisateur est trivial Inacceptable CWE-522: Insufficiently Protected Credentials 6

Solution 1 - hachage naïf Utiliser une fonction de hachage pour stocker le mot de passe Pourquoi pas chiffrer? Car ne résout pas la vulnérabilité de l'employé malicieux qui aura accès à la clé. if (md5($user_password) == $db_password) { return true; } else { return false; } 7

Solution 1 - Problèmes Mots de passes identiques faciles à identifier o md5('bozo') == md5('bozo') = e1c8d6347c0c24e5cbc60e508f3fc1b5 Vulnérable aux attaques par dictionnaire Vulnérable aux attaques par rainbow tables Le problème ici c'est que les mots de passe stockés dans votre base de données partagent le même domaine de possibilités que tous les mots de passe stockés avec le même algorithme de hachage à travers le monde. Donc vous êtes vulnérable au 'hash pre-computation'. CWE-759: Use of a One-Way Hash without a Salt 8

Craquage de mots de passe Attaque par dictionnaire (dictionary attacks) o Passer tous les mots d'une liste à travers le même algorithme de hachage afin d'obtenir la même valeur que dans la base de données o Listes génériques style dictionnaire o Listes spécialisés tirés de statistiques o On peut adapter les listes selon le contexte connu du mot de passe (taille min/max, chiffre obligatoire, etc.) o Limité par la vitesse d exécution de la fonction de hachage o Outils: john the ripper o Exemples de listes http://www.skullsecurity.org/wiki/index.php/passwords Attaque exhaustive (brute-force attack) o On tente itérativement toutes les valeurs de mots de passe crédibles o Plus complet mais beaucoup plus long o Outils: john, crunch 9

Craquage de mots de passe (suite) Rainbow tables o Calcul d'avance de plusieurs millions d'empreintes stockés de façon à éviter les redondances et rendre les recherches rapides o Compromis temps vs mémoire o Plusieurs sont disponibles sur Internet: http://www.freerainbowtables.com/en/tables2/ o Des front end Web existent: http://rainbowtables.g3nius.org/ o Temps à craquer dépend de la grosseur de la table et de la vitesse de cherche dans la table Performance (des attaques exhaustives ou par dictionnaire) o L'utilisation de cartes graphiques (GPU) pour craquer les mots de passe ont amélioré grandement les performances des attaques o "Recovery speed on ATI HD 5970 peaks at 5600M/s MD5 hashes and 2300M/s SHA1 hashes" "J'ai deux cartes ATI en crossfire, je fais environ 5 milliard d'empreintes par seconde pour du MD5." -- Anonyme en 2011 10

Solution 2 - hachage + sel naïf L'ajout d'un sel (salt) consiste à concaténer une chaîne aléatoire au mot de passe avant de l'envoyer dans la fonction de hachage Le sel est stocké avec le mot de passe dans la base de données define('salt', '377fba9d324d42e92dd21a003ec414a9'); function computehash($plaintext) { return sha1(salt. $plaintext); } Résoud le problème des rainbow tables populaires Complexifie l'attaque dictionnaire et exhaustives 11

Solution 2 - Problèmes Permet toujours le pré-calcul de rainbow tables car le sel (salt) est global Permet d'attaquer la base de données en entier avec une attaque de dictionnaire ou exhaustive car le sel est global Mot de passes identiques vont toujours être évidents à l'oeil CWE-760: Use of a One-Way Hash with a Predictable Salt 12

Solution 3 - hachage + sel Ajouter le sel (salt) sur chaque mot de passe au lieu de globalement. On stocke le sel directement dans le champ password. Les attaquant doivent maintenant tenter de craquer chaque entrée de la table de mot de passe séparément define('salt_length', 9); function generatehash($plaintext, $salt = null) { if ($salt == null) { $salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH); } else { $salt = substr($salt, 0, SALT_LENGTH); } return $salt. sha1($salt. $plaintext); } C'est une très bonne solution! Améliorations possibles? 13

Solution 4 - key stretching Problème: Les fonctions de hachage ont été conçues pour être performantes pourtant la vitesse est votre ennemi ici car rapide veut dire qu'un attaquant peut rapidement faire son attaque exhaustive Solution o En plus du sel par mot de passe, o On fait 1000 itérations de l'empreinte dans une boucle o ou encore, on concatène 1000 fois le mot de passe et le sel avant de faire l'empreinte Ici on ralentit l'attaquant de 1000 fois mais on ne peut se permettre se genre de ressources pour authentifier un usager Presque parfait, que manque-t-il? 14

Solution 5 - planifier pour l'avenir Problème: Toutes les solutions stockent l'empreinte dans un format inflexible qui ne permet pas de changer la technique d'empreinte dans l'avenir Solution o Se faire un petit standard interne pour contenir un id de version de votre technique qui décrit le format utilisé o Laisser assez de place dans la colonne pour pouvoir grossir l'empreinte o ex: $1$salt$hash$ 1 = md5 avec 100 itérations et un salt de 64 bit o Planifier la migration du format de mot de passe lorsqu'un utilisateur s'authentifie si id = 1 et default id = 2 on le passe a version 2 15

Les extras PBKDF2 (RFC2898) o meilleure pratique couvrant exactement la solution établie dans ses diapositives o la technique de WPA2 valider un mot de passe d'un nouvel utilisateur contre des dictionnaires populaires comptes 'canary' avec des login / pass / emails obscurs o Vous informe si vous êtes compromis. Séparer sur des serveurs différents l'authentification des comptes et le reste de l'application o pour que l'interface soit très limitée et prévienne toute injection ou XSS possible 16

Le futur Hachage adaptatif (Adaptive hashing) o L'avantage principal c'est qu'on peut le rendre paramétrable. À mesure que les ordinateurs sont plus rapides, la technique de hachage reste difficile à compromettre. o ex: bcrypt scrypt o Nouveau type de problèmes "memory-hard" donc non seulement difficile sur le CPU mais aussi sur la mémoire vive de façon à ce que ce soit difficile d'implémenter une machine matérielle concentrée sur le crackage de mot de passe (FPGA). 17

Conclusion La réutilisation de mots de passe est un fait confirmé. Afin de défendre ses utilisateurs, il faut appliquer une méthode de hachage appropriée L'idéal c'est de ne pas inventer son propre stockage de mot de passe o Par ex: les gens réputés de Openwall on fait phpass qui est une implémentation des meilleurs pratiques (basé sur bcrypt) en PHP sous licence domaine publique: http://www.openwall.com/phpass/ Si vous faites "j'ai oublié mon mot de passe" et que vous recevez votre mot de passe en clair, pensez-y bien! 18

Réfé rences Password Reuse Is All Too Common, Research Shows, http://www.pcworld.com/businesscenter/article/2193 03/password_reuse_is_all_too_common_research_shows.ht ml CWE-257: Storing Passwords in a Recoverable Format, http://cwe.mitre.org/data/definitions/257.html Password lists, http://www.skullsecurity.org/wiki/index.php/passwords Rainbow Tables, http://en.wikipedia.org/wiki/rainbow_table Free Rainbow Tables, http://www.freerainbowtables.com/en/tables2/ IGHASHGPU, attaques exhaustives par GPU, http://www.golubev.com/hashgpu.htm 19

Réfé rences CWE-522: Insufficiently Protected Credentials, http://cwe.mitre.org/data/definitions/522.html CWE-759: Use of a One-Way Hash without a Salt, http://cwe.mitre.org/data/definitions/759.html CWE-760: Use of a One-Way Hash with a Predictable Salt, http://cwe.mitre.org/data/definitions/760.html CAPEC-49: Password Brute Forcing, http://capec.mitre.org/data/definitions/49.html The Importance of Being Canonical, Robert David Graham, http://erratasec.blogspot.com/2009/02/importance-of-being-canonical.html Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes, Thomas Ptacek, http://chargen.matasano.com/chargen/2007/9/7/enough-withthe-rainbow-tables-what-you-need-to-know-about-s.html PHP Security Consortium: Password Hashing, http://phpsec.org/articles/2005/passwordhashing.html Portable PHP password hashing framework, Openwall, http://www.openwall.com/phpass/ Passwords lists and dictionaries, http://www.skullsecurity.org/wiki/index.php/passwords Stronger Key Derivation via Sequential Memory-Hard Functions, Colin Percival, http://www.tarsnap.com/scrypt/scrypt.pdf 20