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

Web : Stockage de mot de passe

LOG619 Automne 2011

Olivier Bilodeau

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:

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.

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;

}

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 ⁸

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

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 ¹⁰

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);

}

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);

}

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

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

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,

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-with- the-rainbow-tables-what-you-need-to-know-about-s.html

PHP Security Consortium: Password Hashing, http://phpsec.org/articles/2005/password- hashing.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