Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Mots de passe sécurisés avec PHP 5.5
Je vous présente mon nouvel article : Mots de passe sécurisés avec PHP 5.5.
Vous y découvrirez les mécanismes mis en place par PHP 5.5 pour gérer efficacement les mots de passe et les solutions à appliquer avec les versions inférieures de PHP.
Mots de passe sécurisés avec PHP 5.5
Bonne lecture
Merci pour cet article, ça permet de se mettre à jour.
J'aurais préferé "chiffrer" au lieu de "crypter"
Article très intéressant, merci. C'est toujours bon de rappeler les bonnes pratiques.
Il y a aussi une méthode d'accès à une zone protégée sans mot de passe qui fait son chemin, à coup de opt-in via email et/ou SMS et de token par device de connexion. Ca me semble un très bon moyen de ne pas avoir à stocker des mots de passe et donc ne pas risquer un brute force ou même risquer une connexion frauduleuse à un compte sans validation préalable du device par l'utilisateur.
Excellent article. Il faut orienter les débutants vers les bonnes pratiques dès le début. Je vois encore trop de gens qui créent leurs propres fonctions/classes pour la gestion de mots de passe.
Peut-être faut -il aussi préciser que cette fonction non seulement génère les salts mais les donne ensuite dans le hash retourné, ce qui fait qu'on n'est plus obligé de stocker les salts séparément comme cela se faisait avant.
Simple mais efficace ! J'aurai aimé avoir un tel article à mes débuts en PHP. La sécurité est souvent négligée lors de l'apprentissage des bases et c'est dommage.
Si je peux me permettre un suggestion, une explication plus approfondie sur le salage rendrai l'article parfait !
Pas nécessairementUn site qui vous permet de retrouver votre mot de passe est un site non sécurisé.
J'ai déjà travaillé sur des systèmes où c'est le client qui stocke la clé de décryptage. C'est le couple question/réponse secrètes. C'est moins propre que cette solution, mais ça permet de lui renvoyer son ancien mot de passe et il est content.Pour les mots de passe, le cryptage est une fausse bonne idée puisque l'administrateur du site qui possède la clé de décryptage peut avoir accès à vos informations. De plus la clé de décryptage est en général sur le serveur, un hacker pourrait la trouver, et donc décrypter toutes les données cryptées.
Rien que pour le principe de changer son mot de passe je suis d'accord avec toi, c'est juste qu'il faut éviter de partir du principe que des solutions alternatives ne peuvent exister.
Bon article, merci
Si un site est capable de te renvoyer ton mot de passe, il est nécessairement pas sécurisé puisque ça implique qu'il existe un moyen de trouver le mot de passe en clair. Ce qui implique que, premièrement, l'administrateur du site peut connaître votre mot de passe, et deuxièmement, que si ces mots de passe se retrouve dans la nature, il y a un risque pour que votre mot de passe en clair soit trouvé.Envoyé par TVorace
Ce que semble expliquer TVorace c'est que le moyen de décrypter le mot de passe est détenu par l'utilisateur et non contenu sur le serveur.
C'est certes pas parfait car on est pas à l'abris d'une attaque visant spécifiquement un utilisateur mais ça semble tout même une solution envisageable quand la récupération du mot de passe est un impératif non négociable.
En effet comme l'explique l'article il ne faut pas confondre hachage et chiffrement.
Je n'ai jamais vu de site web utilisant un chiffrement plutôt qu'un hachage, mais c'est vrai que l'on peut l'imaginer (même si pour moi c'est tordu). Cela implique que l'utilisateur doit retenir deux "mots de passe" (le mot de passe en lui même et la clef de chiffrement) mais du coup c'est le second qui deviens irrécupérable ce qui ne résous pas le problème. En plus le client devra toujours donner les deux à chaque connexion. Je vois pas comment il pourrait ne donner que le premier puisque le serveur a besoin du second pour en vérifier la validité, mais peut être existe-il une solution qui m'échappe ?J'ai déjà travaillé sur des systèmes où c'est le client qui stocke la clé de décryptage. C'est le couple question/réponse secrètes. C'est moins propre que cette solution, mais ça permet de lui renvoyer son ancien mot de passe et il est content.
Rien que pour le principe de changer son mot de passe je suis d'accord avec toi, c'est juste qu'il faut éviter de partir du principe que des solutions alternatives ne peuvent exister.
En plus de compliquer les choses, cela rend la solution plus gourmande. Il me semble bien qu'un chiffrement digne de se nom demande bien plus de ressources qu'un hachage même complexe. Et j'ai du mal à imaginer une solution ou la récupération du mot de passe serait impérative et préférable à sa réinitialisation.
Ce que le client veux , le client obtient. tu as beau lui expliquer que c'est pas forcément une bonne idée , si il est têtu faudra te plier à ses enviesEt j'ai du mal à imaginer une solution ou la récupération du mot de passe serait impérative et préférable à sa réinitialisation
Sinon, ya la technique du LDAP : l'authentification (et donc le chiffrement des mots de passe) n'est pas ton problème, c'est celui du LDAP. Bon après, si le LDAP utilise MD5 c'est bof...
Évidemment, ça n'est applicable que sur des applications type Intranet/Extranet et pas sur un site web.
Article 1 : Le client a raison.Ce que le client veux , le client obtient. tu as beau lui expliquer que c'est pas forcément une bonne idée , si il est têtu faudra te plier à ses envies
Article 2 : Si le client a tort, se référer à l'article 1.
Article 3 : Si l'application ne fait pas ce qu'elle devrait faire, c'est votre faute, et ce même si elle fait ce qui a été demandé (cf. article 2)
Modératrice PHP
Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur)
Cherchez un peu avant poser votre question : Cours et Tutoriels PHP - FAQ PHP - PDO une soupe et au lit !.
Affichez votre code en couleurs : [CODE=php][/CODE] (bouton # de l'éditeur) et [C=php][/C]
L'article dit à la fin :
C'est l'inverse, la librairie password_compat fonctionne à partir de la version 5.3.7 et a pour principal objectif de permettre aux utilisateurs en 5.3 et 5.4 d'avoir accès à la même API de hachage des mots de passe que les utilisateurs en 5.5+Il existe de nombreuses alternatives, la plus connue étant très probablement password_compat qui implémente exactement la même API pour des versions de PHP jusqu'à 5.3.7
C'est corrigé merci
Je rajouterais dans la fonction de cryptage le numéro d'utilisateur lié au mot de passe.
$password = $accountId."_".$password;
Afin qu'un hash puisse être utilisé que pour un seul compte.
Ce n est pas nécessaire puisque un sel aléatoire est utilisé pour chaque hash.
C’est bien d’avoir ce genre d’articles sur la sécurité vu le nombre de mauvais tutoriels qu’on trouve sur le net sur le sujet.
J’ai juste noté quelques points, à mon sens, manque un peu de précision pour un sujet qui traite de cryptographie et de sécurité. Je pense que même si l’article est marqué « tout public » c’est toujours mieux d’être assez précis.
C'était une solution intelligente il y a 10 ou 15 ans (…)
Non, honnêtement hacher ses mots de passe sans ajouter un sel n’a jamais été une solution intelligente. Ce n’était pas intelligent il y a 15 ans ni même 20 ans en arrière. C’est une pratique qui est apparue avec l’ère du développement Web et l’arrivée massive de bidouilleurs en sécurité mais ça reste une hérésie.
La mode de MD5 passée, c'est SHA qui a pris la suite. Bien meilleur que MD5 (…)
Non SHA1 n’est pas meilleur que MD5, c’est bonnet-blanc et blanc-bonnet. SHA1 passe juste sur 160 bits au lieu des 128 bits de MD5 mais il est exactement aussi vulnérable que MD5 (et c’est idem pour les SHA256 et plus).
SHA1 , MD5 et compagnies sont conçus pour générer rapidement des empreintes, tandis qu’un algorithme comme BCrypt est conçu pour hacher des données sensibles comme des mots de passe et résister aux attaques par force brute (et pour préciser Bcrypt a été publié en 1999).
on peut encore l'utiliser aujourd'hui notamment si on lui associe un sel pour rendre inutile les rainbow tables.
Non, même avec du sel il faudrait encore rajouter assez de « rounds » pour le rendre lent. SHAx n’est pas fait pour stocker des mots de passe, point final.
Je suis aussi d’accord (à 100%) avec le commentaire de sabotage pour l’utilisation du terme « chiffrer » à la place de « crypter ». Crypter est un barbarisme qui n’a aucun sens en français quand on parle de cryptographie. Autant on peut l’utiliser à l’apéro pour raconter les exploits de Jack Bauer () autant dans un article qui par de sécurité informatique ça pique vraiment les yeux.
Dernier point c’est dommage de ne pas donner un méthode pour migrer en douceur ses mots de passe hachés en MD5/SHAx vers Bcrypt sur un site en production. Ça serait vraiment un plus.
Tant qu'on a pas été amené à gérer des centaines de milliers d'utilisateurs, on restera un "extrémiste" des mots de passes ultra sécurisés.
Il y a des grands noms du e-commerce qui sont capables de vous renvoyer votre mot de passe par mail.
Pourquoi ? Parcequ'ils ne veulent pas imposer à leurs utilisateurs de mémoriser des mdp trop compliqués qu'ils vont oublier.
Quand vous ouvrez votre voiture vous utilisez une clef. Vous la perdez, on vous vole votre voiture. Le risque est réel, mais c'est un bon compromis risque/practicité.
Je connais quelqu'un qui travaille dans une très grosse boite ; on lui demande de changer son mot de passe tous les mois, et il doit avoir 4 mdp pour 4 applis différentes.
Le système est suffisamment "intelligent" pour détecter que les mdp ne doivent pas se ressembler. Résultat : tout le monde écris ses mdp sur un papier mis dans un tiroir ; ils n'ont pas le choix !
Trop de sécurité nuit à la sécurité...
En entreprise et/ou dans un intranet, le mieux reste de centraliser la connexion et l'authentification via l'utilisation d'un Active Directory par exemple.
En tant que particulier, j'ai fini par déléguer ma gestion des passwords à un gestionnaire de password (lastpass en l'occurence). Et y 'a pas à dire, ça marche bien et ça me semble être une excellente alternative.
Je ne suis pas un expert en la matière, mais à ma connaissance personne n'a jamais trouvé de collisions complète en sha1 contrairement au md5 ou il est possible d'en trouver à la demande. L'estimation du coût pour cracker un md5 est 2^18 contre 2^61 (ce qui n'est pas du tout du meme ordre).
Je m'avance peut être un peu, mais je pense qu'un simple hachage sha256 avec sel aléatoire et 1 seul "round" devrait être suffisant pour sécuriser une banque, surtout si on y ajoute une politique de renouvellement des mots de passe.
Quand je dis "vulnérable" je parle de la facilité de lancer une attaque par bruteforce sur un hash SHA1 ou MD5. Pas du risque de collisions. Dans le monde réel les collisions sont rarement exploitées. Sur des systèmes modernes utilisés pour brutforcer les hashs des mots de passe on arrive à des chiffres comme 20 milliards de mots de passe par seconde (rien à voir avec les chiffres de l'article liés dans le tuto) avec l'une ou l'autre des méthodes. OK, à un milliard près en faveur de SHA1... en pratique ça ne change pas chose.
Répondre avec citation
Partager