Lorsque j'étais à mes premières expériences de programmation, j'ai travaillé sur de nombreux projets comportant des sections sécurisées par un nom d'usager et un mot de passe. Les codes d'accès étaient stockés dans une base de données et à ma grande surprise, les mots de passes n'étaient jamais ou très rarement encryptés. Même si parfois le contenu à protéger ne nécessitait pas une confidentialité absolue, je persistais à croire qu'il s'agissait d'une vulnérabilité dans le processus qu'il fallait corriger. D'autre part, le code dynamique des pages web avait été créé à l'aide des wizards de Dreamweaver (horrible!), qui était propice au SQL injection (doublement horrible, même si un correctif est sorti entre temps...). Certaines techniques de SQL injection permettent de contourner les mécanismes de sécurité tandis que d'autres donnent la possibilité d'extraire le nom d'une table, des champs et les données, donc possiblement le nom d'usager et le mot de passe.
Une première approche serait d'encrypter le mot de passe en utilisant un algorithme d'encryption, par exemple MD5 ou SHA1. C'est déjà un premier pas dans la bonne direction. Cependant, si le mot de passe à encrypter était "code 18", le résultat d'hachage (hash value) serait toujours le même :
MD5 : 33165ee9ddbc4cccd441e7bdc08aa606
SHA1 : 965ecafc34288a0db4efe0d1c6cd1c9d2d0c5796
Donc en effectuant une attaque par dictionnaire ou par brute force, c'est possible de réussir à obtenir le hash correspondant au terme utilisé comme mot de passe. C'est d'ailleurs une des raisons pour laquelle on recommande d'y inclure des lettres, des chiffres et des symboles, car le terme ne fera pas parti des tentatives si on est face à un dictionary attack. Pour augmenter la sécurité d'un cran, on pourra y ajouter un "salt".
En cryptographie, un salt est une série de bits qui sont ajoutés au mot de passe pour l'altérer avant qu'il soit encrypté. Ce salt devrait être idéalement aléatoire et différent pour chaque mot de passe. Ceci aura comme avantage que deux mots de passes identiques au départ auront un hash différents à la fin. Voici un exemple qui illustre l'idée du mécanisme d'encryption :
- Lors de la création d'un compte utilisateur, saisir le nom d'usager (unique) et le mot de passe souhaité (exemple : "code 18").
- Générer une chaîne de caractères aléatoire d'une longueur d'au moins 8 caractères (par exemple : gxGPx$Bw). Cette chaîne servira de salt.
- Prendre le mot de passe et y concaténer le salt à la fin (mais pourrait être n'importe où). Ici, si le mot de passe est "code 18", la chaîne deviendra "code 18gxGPx$Bw".
- Encrypter la chaîne résultante pour obtenir le hash en utilisant MD5 ou SHA1 (ou tout autre algorithme). En utilisant SHA1, le résultat deviendra : 762c845c682521188c34af97fd06b53de3ea16e9
- Enregistrer dans la base de données le nom d'usager, le salt et le hash (mais pas le mot de passe).
- L'utilisateur entrera son nom d'usager et son mot de passe original (le salt faisant parti du mécanisme interne, il est transparent à l'usager). Attention, le mot de passe est devenu sensible à la case en raison de l'encryption!
- Prendre le nom d'usager entré et vérifier si un compte existe dans la base de données.
- S'il existe, récupérer le salt et le hash qui correspond à ce compte.
- Concaténer le salt au mot de passe fourni lors de l'authentification.
- Encrypter la chaîne résultante en utilisant le même algorithme d'encryption pour obtenir le hash.
- On autorisera l'accès que si le hash résultant est égal au hash récupéré de la base de données.
hyper intéressant! merci.
Deux autres articles hyper intéressants de Jeff Atwood qui poussent la réflexion plus loin :
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
http://www.codinghorror.com/blog/2012/04/speed-hashing.html