Grouillot !

Transfert d'un mot de passe haché

Le mot de passe d'un utilisateur est personnel, il ne doit jamais quitter le poste de l'utilisateur. Aussi étonnant que cela puisse paraître, il ne faut pas stocker le mot de passe de ses utilisateurs, qu'ils soient chiffrés ou en clairs. Stocker ou faire transiter sur le réseau un mot de passe qu'il soit chiffré ou non représente une faiblesse, car il peut être intercepté et déchiffré. Il est préférable d'opter pour une authentification via l'identifiant et l'empreinte du mot de passe, où l'empreinte du mot de passe est générée côté client (empreinte SHA-256 via javascript par exemple), ainsi le mot de passe ne quitte jamais le poste de l'utilisateur.

L'utilisateur à la fâcheuse tendance à utiliser le même mot de passe partout, avec la présente technique, même si le couple identifiant / empreinte est piraté (via une attaque "man in the middle" ou une attaque du serveur), il sera très difficile pour un pirate de remonter au mot de passe initial de l'utilisateur et, par exemple, de s'identifier sur le compte email de l'utilisateur (qui utilise ce même mot de passe).

Protège d'une attaque "man in the middle" ou lorsque l'attaquant accède à la base de données

Le grain de sel

En complément de la technique précédente, au lieu de stocker l'empreinte du mot de passe, il est possible de stocker l'empreinte du mot de passe PLUS une phrase aléatoire. Cela s'appelle la technique du salage ou du grain de sel. Le but du grain de sel étant de rendre inopérantes les attaques par table de hachage. Exemple : mon mot de passe est "iloveyou" et mon grain de sel est "Z{4uè:@t". L'empreinte stockée en base n'est plus empreinte("iloveyou") mais empreinte("iloveyou.Z{4uè:@t"). Un attaquant organisé pourra facilement, à partir d'une table de hachage des mots de passe usuels, faire la correspondance entre empreinte("iloveyou") et "iloveyou" ... alors qu'il sera très improbable que l'attaquant dispose de la correspondance entre empreinte("iloveyou.Z{4uè:@t") et "iloveyou.Z{4uè:@t" dans sa table de hachage.

L'objectif de la technique du grain de sel est uniquement de rendre caduques les attaques par table de hachage pour un attaquant ayant récupéré tout ou parti de la base de données ... le grain de sel n'est pas un secret, il n'a pas besoin d'être chiffré.

Protège d'une tentative de récupération de mot de passe par correspondance dans une table de hachage.

Guider l'utilisateur boulet dans ses choix

Il faut forcer l'utilisateur à choisir un mot de passe sécurisé. Établir et mettre en place une liste de mot de passe qui ne doivent en aucun cas être utilisés comme par exemple "password", "abcdef", "azerty", "123456" ou un mot de passe contenant l'identifiant de l'utilisateur.

Protège des attaques par force brute.

Eviter les questions de ré-initialisation de mot de passe impersonnelles.

Les questions personnelles, présentes généralement en cas d'oubli du mot de passe votre boite email par exemple, peuvent être facilement contournées. En effet, il n'est peut-être pas évident pour un chinois de "brute-forcer" la question personnelle "Quel est le nom de jeune fille de votre mère ?" mais pour quelqu'un vous connaissant ou faisant partie de votre réseau "facebook" il devient plus aisé de répondre à cette question. Les questions personnelles doivent donc être très personnelles, seul l'utilisateur doit connaitre la réponse à la question.

Protège des attaques d'un "proche" de l'utilisateur.

Repérer et bannir les attaquants

Il est aussi nécessaire de se protéger des attaques par force brute. Là aussi il y a plusieurs solutions au problème, module modsecurity d'Apache, fail2ban, etc... L'important est de blacklister rapidement et pendant un certain temps ces attaques.

Protège les attaques par force brute.

Pour finir ...

Je pense avoir fait le tour des principales techniques pour mieux sécuriser une authentification simple, il est indispensable par ailleurs que les mises à jour de sécurité du serveur web à protéger soit faites, qu'il n'y ait pas de compte générique, de port ouvert, de logiciel douteux... sinon appliquer ces méthodes reviendraient en quelque sorte à mettre des portes blindées sur une voiture décapotable ...

D'une manière générale, il faut prendre assez de recul pour choisir une méthode d'authentification adaptée. On ne n'authentifie pas sur un site web d'une association locale comme sur le site web de sa banque. Tout est question de l'importance des données à protéger. Si ces méthodes pour sécuriser l'authentification vous paraissent trop légères alors il est temps de passer à l'authentification forte.