Les mots de passe sont des informations très privées et vous ne voulez pas être responsable d'une violation de données. Vous devez prendre les plus hautes précautions si vous devez les manipuler dans votre application et les hacher correctement.

La plupart des problèmes de sécurité liés aux mots de passe surviennent après qu'un attaquant a accédé à votre serveur et est en mesure d'afficher la base de données dans laquelle vous stockez les mots de passe. Bien que ce soit définitivement une bonne idée de verrouiller votre serveur pour empêcher tout accès non autorisé en premier lieu, vous devez toujours mettre en œuvre un contrôle des dommages dans le pire des cas.

Utilisez plutôt OAuth, si vous le pouvez

La meilleure façon de gérer les mots de passe n'est pas du tout. Sauf si vous avez un besoin spécifique de gérer directement les mots de passe, vous pouvez utiliser OAuth pour que quelqu'un d'autre le gère à votre place. Cela s'appelle également la connexion par un tiers, et vous l'avez probablement déjà rencontrée si on vous a déjà demandé de vous connecter avec Google ou Facebook.

OAuth est plus compliqué que l'authentification par mot de passe, mais même si vous êtes complètement compromis, il n'y a aucune donnée de mot de passe pour un attaquant, pas même les hachages.

Ne jamais stocker les mots de passe en texte clair

Si vous devez stocker des mots de passe, vous ne devez jamais les stocker en texte clair sur votre serveur. "Texte en clair" signifie qu'il est lisible par un attaquant ayant accès à votre disque. Par exemple, si vous prenez simplement le mot de passe d’un utilisateur et que vous le stockez dans votre base de données MySQL, vous le stockez en texte brut. C'est pourquoi vous recevez toujours un lien pour réinitialiser votre mot de passe au lieu que l'entreprise vous dise simplement quel était votre ancien mot de passe.

La solution au problème du texte brut est le hachage. Un hachage est une fonction qui prend une valeur et génère une clé unique. Par exemple, l'expression "mot de passe”A un hachage SHA256 de:

6B3A55E0261B0304143F805A24924D0C1C44524821305F31D9277843B8A10F4E

Mais en changeant ne serait-ce qu'un seul chiffre (passwerd) modifie complètement la sortie:

0B503AEB841F18131DFA86FA052CEF91D9F4D81D301B89F6D035AF89C2CD8AA5

Ainsi, plutôt que de stocker le mot de passe sur le serveur, vous stockez ce hachage. Les hachages sont différents du chiffrement en ce qu'ils sont des fonctions à sens unique. Vous pouvez hacher quelque chose, mais il est impossible de le «libérer» sans simplement renforcer brutalement le hachage. Cela signifie qu'il n'y a pas de clé secrète à stocker, et même si un attaquant met la main sur un hachage, il devra d'abord la forcer brutalement pour voir le contenu.

Cette règle en texte brut s'applique également aux éléments auxiliaires tels que les fichiers journaux. Si l'attaquant peut le lire de n'importe où, c'est un problème majeur. Cela s'applique également aux méthodes de transmission de texte en clair comme HTTP, bien que vous ne devriez jamais envoyer de mots de passe sur le fil de toute façon. Vous souhaitez générer un hachage côté client lorsqu'ils le saisissent, pour éviter que les mots de passe ne soient reniflés sur le réseau.

Même si la sécurisation du trafic avec HTTPS empêcherait les attaques de type "man-in-the-middle" côté client, si un attaquant avait accès à votre serveur, il pourrait déchiffrer et renifler les mots de passe nouvellement créés. Cela rend également votre service plus fiable, car un utilisateur ne saura pas si vous stockez secrètement son mot de passe dans les coulisses. Mais si vous ne voyez qu'un hachage, même le serveur ne sait pas quel est son mot de passe.

Si vous voulez simplement utiliser un bon hachage, choisissez PBKDF2, car il est utilisé spécifiquement pour stocker les mots de passe et est très sécurisé. Vous souhaiterez probablement utiliser le Implémentation JavaScript côté client, mais si vous devez l'utiliser côté serveur, vous souhaiterez utiliser une implémentation pour votre langue.

Sel vos mots de passe

Le hachage a un problème et les hachages de mots de passe normaux peuvent être piratés avec une méthode connue sous le nom de tables arc-en-ciel.

Pour attaquer un hachage, vous pouvez simplement essayer tous les mots de passe possibles pour chaque entrée de hachage de votre base de données, ce que l'on appelle le bruteforcing – lent, mais pas entièrement impossible, selon la faiblesse du mot de passe et le hachage utilisé pour le stocker. Cela peut prendre quelques jours ou semaines de temps de calcul, mais un mot de passe faible individuel pourrait éventuellement être craqué.

Les tables arc-en-ciel accélèrent considérablement cela. Plutôt que de forcer chaque mot de passe individuellement, les hachages pour chaque mot de passe possible sont calculés à l'avance et stockés dans un fichier. Ce fichier peut être massif, à l’échelle de plusieurs centaines de téraoctets. Il s'agit simplement d'une paire clé-valeur de chaque mot de passe possible (jusqu'à une certaine taille, selon la table), et du hachage correspondant.

C’est un compromis entre l’espace de stockage et le temps; vous ne devez effectuer le hachage qu'une seule fois, puis vous pouvez le rechercher dans la table à la place (ce qui est beaucoup plus rapide). Ces tableaux sont accessibles au public et faciles à générer.

Pour éviter ce vecteur d'attaque, vous devez ajouter un salt – une chaîne aléatoire que vous ajoutez à la fin du mot de passe avant le hachage. Au lieu de hacher "mot de passe", Vous hacheriez:

mot de passe + 1D75BCA3 ...

Ce sel est stocké avec le hachage du mot de passe dans la base de données. Lorsqu'un utilisateur entre son mot de passe, vous renvoyez le sel à l'utilisateur afin qu'il puisse l'ajouter au hachage. Vous pouvez y penser comme chaque utilisateur ayant sa propre table arc-en-ciel unique, ce qui va à l'encontre de son objectif.

Le sel lui-même n’est pas un secret. Ce n'est pas nécessaire, car tout ce qu'il fait est d'empêcher la création de table arc-en-ciel, et vous le stockez de toute façon en texte brut. Les mots de passe salés peuvent toujours être brutalisés individuellement.

En pratique, les tailles de hachage de 32 octets sont assez courantes, car les hachages très courts sont toujours vulnérables aux tables arc-en-ciel. Et ne réutilisez pas les sels; vous devez générer une nouvelle chaîne aléatoire à chaque fois.

Utilisez un hachage sécurisé pour les mots de passe

Bien que SHA256 soit un hachage sécurisé, il est également conçu pour être un hachage à usage général. Cela signifie qu'il doit être rapide, car il est également utilisé pour créer des sommes de contrôle (qui doivent traiter des gigaoctets de données). La vitesse réduit directement le temps de renforcement brutal, et même avec des mots de passe salés, il est encore relativement facile de casser des chaînes courtes individuelles. Les sels ne protègent que contre les tables arc-en-ciel.

Au lieu de cela, utilisez PBKDF2. Il est spécifiquement conçu pour les mots de passe, ce qui signifie qu’il est relativement lent à calculer le mot de passe de longueur moyenne. Le bruteforce prend beaucoup plus de temps et il est pratiquement impossible de déchiffrer les mots de passe plus longs qui y sont stockés. Vous pouvez utiliser le Implémentation JavaScript, ou utilisez un implémentation côté serveur.

Pour tirer pleinement parti de PBKDF2, vous souhaiterez mettre en œuvre une sorte de norme de mot de passe pour votre site. Vous n’avez pas besoin d’exiger de tout le monde qu’il y ait des signes dollar et des chiffres; la longueur compte beaucoup plus que toute autre chose. Essayez d'appliquer des mots de passe de 8 à 12 caractères au minimum.

Une dernière liste de contrôle

En terminant, voici une liste de contrôle de sécurité pour vous assurer que vous êtes prêt:

• Évitez d'utiliser des mots de passe et passez à OAuth si possible.
• Ne stockez jamais de mots de passe en clair dans une base de données, un journal ou un fichier et ne les transmettez jamais via des connexions HTTP.
• Hash des mots de passe avec une fonction de hachage sécurisée comme PBKDF2 ou SHA256.
• Ajoutez toujours un sel aléatoire à vos hachages de mot de passe et stockez-le à côté du hachage.
• Évitez d'utiliser MD5 ou SHA1. (Ils ont tous deux été brisés et ne sont pas en sécurité.)
• Appliquez des normes de mot de passe décentes pour les utilisateurs de votre site. (La longueur est la clé ici.)
• Idéalement, gardez votre serveur totalement ignorant des mots de passe en texte brut en effectuant le hachage côté client. Cette protection par mot de passe à l'épreuve du temps, même dans le cas où un attaquant obtiendrait un accès complet à la mémoire de votre serveur.
• Assurez-vous que le serveur lui-même est sécurisé en verrouillant l'accès SSH et en gardant tout à jour, de sorte que vous n'aurez probablement jamais ce problème en premier lieu.