AVERTISSEMENT : Cette réponse a été écrite en 2008.
Depuis lors, PHP nous a donné password_hash
et password_verify
et, depuis leur introduction, ils sont les mots de passe a recommandé et méthode de vérification.
La théorie de la réponse reste cependant une bonne lecture.
TL; DR
À ne pas faire
- Ne limitez pas les caractères que les utilisateurs peuvent saisir pour les mots de passe. Seuls les idiots le font.
- Ne limitez pas la longueur d'un mot de passe. Si vos utilisateurs veulent une phrase contenant supercalifragilisticexpialidocious, ne les empêchez pas de l'utiliser.
- Ne supprimez pas et n'échappez pas le HTML et les caractères spéciaux dans le mot de passe.
- Ne stockez jamais le mot de passe de votre utilisateur en texte brut.
- N'envoyez jamais de mot de passe à votre utilisateur, sauf s'il a perdu le sien et que vous en avez envoyé un temporairement.
- Jamais, jamais enregistrer les mots de passe de quelque manière que ce soit.
- Ne hachez jamais les mots de passe avec SHA1 ou MD5 ou même SHA256! Les crackers modernes peuvent dépasser 60 et 180 milliards de hachages / seconde (respectivement).
- Ne mélangez pas bcrypt et avec la sortie brute de hash () , utilisez la sortie hexadécimale ou base64_encode. (Cela s'applique à toute entrée pouvant contenir un voyou
\0
, ce qui peut sérieusement affaiblir la sécurité.)
Dos
- Utilisez scrypt quand vous le pouvez; bcrypt si vous ne pouvez pas.
- Utilisez PBKDF2 si vous ne pouvez pas utiliser bcrypt ou scrypt, avec des hachages SHA2.
- Réinitialisez les mots de passe de tout le monde lorsque la base de données est compromise.
- Implémentez une longueur minimale raisonnable de 8 à 10 caractères, et exigez au moins 1 lettre majuscule, 1 lettre minuscule, un chiffre et un symbole. Cela améliorera l'entropie du mot de passe, ce qui le rendra plus difficile à déchiffrer. (Voir la section «Qu'est-ce qui fait un bon mot de passe?» Pour un débat.)
Pourquoi hacher les mots de passe de toute façon?
L'objectif derrière le hachage des mots de passe est simple: empêcher l'accès malveillant aux comptes d'utilisateurs en compromettant la base de données. Le but du hachage de mot de passe est donc de dissuader un pirate ou un pirate en leur coûtant trop de temps ou d'argent pour calculer les mots de passe en texte brut. Et le temps / coût sont les meilleurs moyens de dissuasion dans votre arsenal.
Une autre raison pour laquelle vous voulez un bon hachage robuste sur les comptes d'utilisateurs est de vous donner suffisamment de temps pour changer tous les mots de passe du système. Si votre base de données est compromise, vous aurez besoin de suffisamment de temps pour au moins verrouiller le système, sinon changer chaque mot de passe de la base de données.
Jeremiah Grossman, CTO de Whitehat Security, a déclaré sur le blog de White Hat Security après une récente récupération de mot de passe qui nécessitait une rupture par force brute de sa protection par mot de passe:
Fait intéressant, en vivant ce cauchemar, j'ai appris BEAUCOUP que je ne connaissais pas sur le craquage de mot de passe, le stockage et la complexité. J'en suis venu à comprendre pourquoi le stockage des mots de passe est toujours plus important que la complexité des mots de passe. Si vous ne savez pas comment votre mot de passe est stocké, alors tout ce dont vous pouvez vraiment compter est la complexité. Cela peut être une connaissance courante pour les professionnels du mot de passe et de la cryptographie, mais pour l'expert moyen d'InfoSec ou de la sécurité Web, j'en doute fortement.
(Je souligne.)
Qu'est-ce qui fait un bon mot de passe de toute façon?
Entropie . (Non pas que je souscrive pleinement au point de vue de Randall.)
En bref, l'entropie correspond à la variation du mot de passe. Lorsqu'un mot de passe n'est composé que de lettres romaines minuscules, cela ne représente que 26 caractères. Ce n'est pas beaucoup de variation. Les mots de passe alphanumériques sont meilleurs, avec 36 caractères. Mais autoriser les majuscules et les minuscules, avec des symboles, est d'environ 96 caractères. C'est bien mieux que de simples lettres. Un problème est que pour rendre nos mots de passe mémorables, nous insérons des modèles, ce qui réduit l'entropie. Oops!
L'entropie de mot de passe est approximée facilement. L'utilisation de la gamme complète de caractères ascii (environ 96 caractères typables) donne une entropie de 6,6 par caractère, ce qui à 8 caractères pour un mot de passe est encore trop faible (52,679 bits d'entropie) pour une sécurité future. Mais la bonne nouvelle est que les mots de passe plus longs et les mots de passe avec des caractères unicode augmentent vraiment l'entropie d'un mot de passe et le rendent plus difficile à déchiffrer.
Il y a une discussion plus longue sur l'entropie des mots de passe sur le site Crypto StackExchange . Une bonne recherche Google donnera également de nombreux résultats.
Dans les commentaires, j'ai parlé à @popnoodles, qui a souligné que l' application d' une politique de mot de passe de longueur X avec X nombreuses lettres, chiffres, symboles, etc., pouvait en fait réduire l'entropie en rendant le schéma de mot de passe plus prévisible. Je suis d'accord. L'aléatoire, aussi aléatoire que possible, est toujours la solution la plus sûre mais la moins mémorable.
Pour autant que j'ai pu le dire, créer le meilleur mot de passe au monde est un Catch-22. Soit ce n'est pas mémorable, trop prévisible, trop court, trop de caractères Unicode (difficile à taper sur un appareil Windows / Mobile), trop long, etc. Aucun mot de passe n'est vraiment assez bon pour nos besoins, nous devons donc les protéger comme s'ils étaient à Fort Knox.
Les meilleures pratiques
Bcrypt et scrypt sont les meilleures pratiques actuelles. Scrypt sera meilleur que bcrypt dans le temps, mais il n'a pas été adopté en tant que norme par Linux / Unix ou par les serveurs Web, et n'a pas encore fait l'objet d'un examen approfondi de son algorithme. Mais encore, l'avenir de l'algorithme semble prometteur. Si vous travaillez avec Ruby, il y a un joyau scrypt qui vous aidera et Node.js a maintenant son propre package scrypt . Vous pouvez utiliser Scrypt en PHP via l' extension Scrypt ou l' extension Libsodium (les deux sont disponibles dans PECL).
Je suggère fortement de lire la documentation de la fonction crypt si vous voulez comprendre comment utiliser bcrypt, ou vous trouver un bon wrapper ou utiliser quelque chose comme PHPASS pour une implémentation plus héritée. Je recommande un minimum de 12 tours de bcrypt, sinon 15 à 18.
J'ai changé d'avis sur l'utilisation de bcrypt lorsque j'ai appris que bcrypt utilise uniquement le calendrier des clés de blowfish, avec un mécanisme de coût variable. Ce dernier vous permet d'augmenter le coût de la force brute d'un mot de passe en augmentant le calendrier de clés déjà cher de Blowfish.
Pratiques moyennes
Je ne peux presque plus imaginer cette situation. PHPASS prend en charge PHP 3.0.18 à 5.3, il est donc utilisable sur presque toutes les installations imaginables et doit être utilisé si vous ne savez pas avec certitude que votre environnement prend en charge bcrypt.
Mais supposons que vous ne puissiez pas utiliser du tout bcrypt ou PHPASS. Et alors?
Essayez une implémentation de PDKBF2 avec le nombre maximal de tours que votre environnement / application / perception de l'utilisateur peut tolérer. Le nombre le plus bas que je recommanderais est de 2500 tours. Assurez-vous également d'utiliser hash_hmac () s'il est disponible pour rendre l'opération plus difficile à reproduire.
Pratiques futures
Venir en PHP 5.5 est une bibliothèque de protection par mot de passe complète qui résume toutes les difficultés de travailler avec bcrypt. Alors que la plupart d'entre nous sont bloqués avec PHP 5.2 et 5.3 dans la plupart des environnements courants, en particulier les hôtes partagés, @ircmaxell a construit une couche de compatibilité pour la prochaine API qui est rétrocompatible avec PHP 5.3.7.
Récapitulatif de la cryptographie et avis de non-responsabilité
La puissance de calcul requise pour réellement casser un mot de passe haché n'existe pas. La seule façon pour les ordinateurs de "casser" un mot de passe est de le recréer et de simuler l'algorithme de hachage utilisé pour le sécuriser. La vitesse du hachage est linéairement liée à sa capacité à être forcé par la force brute. Pire encore, la plupart des algorithmes de hachage peuvent être facilement parallélisés pour fonctionner encore plus rapidement. C'est pourquoi les schémas coûteux comme bcrypt et scrypt sont si importants.
Vous ne pouvez pas prévoir toutes les menaces ou voies d'attaque, et vous devez donc faire de votre mieux pour protéger vos utilisateurs à l'avance . Si vous ne le faites pas, vous pourriez même manquer le fait que vous avez été attaqué jusqu'à ce qu'il soit trop tard ... et vous êtes responsable . Pour éviter cette situation, agissez paranoïaque pour commencer. Attaquez votre propre logiciel (en interne) et tentez de voler les informations d'identification de l'utilisateur, ou de modifier les comptes d'autres utilisateurs ou d'accéder à leurs données. Si vous ne testez pas la sécurité de votre système, vous ne pouvez blâmer personne d'autre que vous-même.
Enfin: je ne suis pas cryptographe. Tout ce que j'ai dit, c'est mon opinion, mais je pense que c'est basé sur le bon vieux bon sens ... et beaucoup de lecture. N'oubliez pas, soyez aussi paranoïaque que possible, rendez les choses aussi difficiles à empiéter que possible, puis, si vous êtes toujours inquiet, contactez un pirate à chapeau blanc ou un cryptographe pour voir ce qu'ils disent de votre code / système.