Web : Stockage de mot de passe

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
10
seconde pour du MD5." -- Anonyme en 2011
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);
}
13
C'est une très bonne solution! Améliorations possibles?
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
14
Presque parfait, que manque-t-il?
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