Discussion :

[grunk]

La RFC "password_hash" vient d'être acceptée et sera ajoutée à PHP 5.5


Pourquoi cette nouvelle API ?
Généralement lorsque l'on parle de hash de mot de passe les utilisateurs se tournent vers md5 ou sha, deux algorithmes qui ne devraient plus être utilisés (nombreuses rainbow tables, failles dans l'algorithme ...)

Une solution efficace pour hasher ses mots de passe est l'utilisation de bcrypt mais malheureusement peu de développeurs l'utilisent notamment à cause de la fonction crypt() de php qui n'est pas des plus faciles à utiliser.

Cette nouvelle API vient donc combler ce manque avec une solution simple et efficace pour protéger ses mots de passe.


Comment ça marche ?
La RFC propose quatre nouvelles fonctions, deux nous intéressent particulièrement puisqu'elles permettent de hasher et vérifier un hash :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
password_hash($password, $algo, $options = array());
password_verify($password, $hash);

Pour hasher et vérifier un mot de passe, c'est donc très simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$password = "motdepasse";
$hash = password_hash($password, PASSWORD_BCRYPT, array("cost" => 10));
 
if (password_verify($password, $hash)) {
    echo 'Mot de passe OK';
} else {
    echo 'Erreur mot de passe';
}

Vous aurez remarqué la spécification d'un coût dans les options, ce coût définit la complexité du mot de passe. Plus le coût est élevé plus le hash est long à obtenir et par conséquent difficile à attaquer.

Avec cette API, plus besoin de se soucier des salts aléatoires, tout est géré en interne, le développeur n'a plus qu'à protéger son mot de passe.

La compatibilité future n'a pas été oubliée puisque grâce à password_needs_rehash il sera possible de rehasher un mot de passe si l'algorithme par défaut évolue.


Je n'ai pas PHP 5.5 !
Tout n'est pas perdu , il existe de nombreuses implémentations de bcrypt en PHP. Tel que phpass


Toutes les infos et des exemples sur la RFC password_hash : voir

[transgohan]

Sympatoche, jusqu'à maintenant j'utilisais ma propre class effectuant la même chose mais en utilisant blowfish.
Mais sinon je vois pas tellement en quoi crypt() est difficile à utiliser...

Edit : hum... BCRYPT = BLOW_FISH ?
Bon au final à part normaliser ce que j'utilisais déjà ça me changera rien...

[grunk]

Mais sinon je vois pas tellement en quoi crypt() est difficile à utiliser...

C'est pas tant la syntaxe qui est compliqué mais plutôt les arguments à lui passer qui nécessite des connaissance en cryptage pour savoir quoi utiliser.

Là avec cette nouvelle API , pas de question à se poser , pas besoin de connaitre les différents algorithmes. Bref c'est plus simple et on évite les erreurs

[YannouFromMars]

Il existe même une librairie qui permet d'assurer la compatibilité avec les versions antérieures à la 5.5 : https://github.com/ircmaxell/password_compat

[raimbow]

Je comprend pas comment le salt peut être géré en interne ?

C'est une chaîne qu'on définis dans le php.ini ? En cas de changement de serveur comment ça se passe pour conserver le même grain ?

Et la fonction password_verify() elle fait juste un password_hash($password) puis un === ou bien c'est plus complexe que ça ?

[Nathanael Marchand]

Il manque une parenthèse dans le dernier exemple, juste avant le point virgule : ("cost" => 10);

Par contre, j'ai du mal à voir comment password_verify fonctionne. En supposant que password_hash est paramétrable (puisqu'on a l'air de pouvoir passer l'algo et la complexité), je vois pas comment on peut faire la comparaison pour savoir si le password est bon car il faut réhasher avec les mêmes paramètres et comparer ceci or password_verify lui ne prend pas de paramètres.
Si quelqu'un peut éclairer ma lanterne ca serait top!

[Thorna]

J'imagine que la valeur du hash contient quelques infos sur la manière dont il a été calculé, permettant de vérifier par la suite ?
Ou bien il existe, parallèlement à l'algo de chiffrage, un algo de vérif qui profite de quelques particularités mathématiques de la méthode de chiffrage ?

[Grabeuh]

La chaine retournée par password_hash() contient à la fois le l'algo + l'indice de complexité + le sel + le hash.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
"$2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi"
//$2a pour l'algo blowfish
//$07 pour une complexité de 7
//$usesomesillystringfor est le salt, il commence par $ et la chaine fait 22 caractères au total en comptant le $. Si lors du hashage on met une chaine plus longue, elle est tronquée.
//le reste est la chaine "rasmuslerdorf" hashé par l'algo

C'est le fonctionnement classique de crypt, dont la nouvelle API doit être une surcouche simplifiée.
Et oui, pour effectuer la comparaison, on repasse le mot de passe en clair à la moulinette et on le compare au hash. Les informations de cryptage (algo, complexité et sel) sont extraites de la chaine du hash.

[grunk]

Il manque une parenthèse dans le dernier exemple, juste avant le point virgule : ("cost" => 10);

Merci c'est corrigé

Si quelqu'un peut éclairer ma lanterne ca serait top!

Grabeuh l'explique très bien dans sa réponse précédente , le hash retourné par la fonction comprend toutes les infos nécessaire pour le comparer.

Pour ceux que ca interesse une implémentation de bcrypt en php : https://github.com/grunk/Pry/blob/ma...rypt.class.php ca peut aider à comprendre le principe

[GATEN]

Donc si je comprend bien, avec cette nouvelle méthode, en BDD on stocke à la fois l'algo + l'indice de complexité + le sel + le hash.

Mais si une personne mal intentionnée récupére ma BDD et même si elle a toute ces infos, il lui sera impossible de déchiffrer et de retrouver le mot de passe en clair ?

Pour ma part, j'ai toujours stocké le hash dans la BDD et le sel dans mon code source... N'est-ce pas mieux ainsi ?

Et que pensez-vous de la solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$mon_hash = sha1("v'la_du_gros_sel".md5("sel_de_mer"."PASS"));

[Nathanael Marchand]

Merci c'est corrigé


Grabeuh l'explique très bien dans sa réponse précédente , le hash retourné par la fonction comprend toutes les infos nécessaire pour le comparer.

Pour ceux que ca interesse une implémentation de bcrypt en php : https://github.com/grunk/Pry/blob/ma...rypt.class.php ca peut aider à comprendre le principe

Ca me va bien comme réponse! Merci

[grunk]

Mais si une personne mal intentionnée récupére ma BDD et même si elle a toute ces infos, il lui sera impossible de déchiffrer et de retrouver le mot de passe en clair ?

Il ne peux pas retrouver le mot de passe en clair puisqu'un hash n'est pas réversible. Tout ce qu'il peux faire c'est éventuellement un brute force mais comme cet algo est conçu pour être très lent (un seul hash peut prendre de quelques ms à pls seconde selon la complexité) , ça va être très très très long.

Après ca ne protège pas des utilisateurs négligents qui utilisent des mdp du genre "azerty" ou "123"

[raimbow]

Merci pour les infos

ça me semble très sympa comme méthode de fonctionnement, je vais étudier ça d'un peu plus près.

Pour ma part, j'ai toujours stocké le hash dans la BDD et le sel dans mon code source... N'est-ce pas mieux ainsi ?

Et que pensez-vous de la solution :

Le soucis c'est que là tu va utiliser un grain de sel commun à toute ta base de donnée. Sur un petit site avec quelques dizaine ou centaine d'utilisateurs c'est pas vraiment un problème, mais sur un site avec plusieurs milliers de comptes, ça vaut le coup de se créer des raimbow table avec le grain de sel que tu à mis dans ton code source et de pouvoir ainsi facilement retrouver tous les mots de passes.

Si tu utilise un grain de sel différent à chaque fois il faudra tester tous les mots de passe possible pour chaque utilisateur et ça sera beaucoup trop long pour être faisable.


Après l'idée de stocker le grain de sel à autre endroit de la BDD ne me semble pas complètement idiot car ce n'est pas rare que la BDD soit piraté mais pas le code source de l'application. Une solution qui combine tous les avantages c'est de faire un truc du genre $hash = md5('GDS_Code_Source' . $user['gds_bdd'] . $password);

Comme ça le pirate doit avoir accès a la BDD + au code source et il ne pourra même pas se créer de raimbow table vu qu'il y'a un grain de sel par compte.

[moosh]

Je suis étonné que les clés du tableau d'option ne soient pas des constantes.

[Neckara]

Si je comprend bien, plutôt que d'envoyer le hash de son mot de passe, le client va envoyer son mot de passe au serveur afin que ce dernier puisse recalculer le hash ?

Je ne suis pas expert en sécurité mais ça veut dire qu'à un moment ou un autre, le serveur est capable de retrouver le mot de passe en clair et je doute que ce soit une bonne chose... non?

[matll]

Si je comprend bien, plutôt que d'envoyer le hash de son mot de passe, le client va envoyer son mot de passe au serveur afin que ce dernier puisse recalculer le hash ?

Je ne suis pas expert en sécurité mais ça veut dire qu'à un moment ou un autre, le serveur est capable de retrouver le mot de passe en clair et je doute que ce soit une bonne chose... non?

Je ne suis pas expert non plus, mais je suis d'accord avec Neckara. Une attaque de type man in the middle permet ici facilement de récupérer un mot de passe (sauf erreur de ma part). Le mieux n'est-il pas d'encoder le mot de passe côté client avant envoi ?

[Grabeuh]

Je ne suis pas expert non plus, mais je suis d'accord avec Neckara. Une attaque de type man in the middle permet ici facilement de récupérer un mot de passe (sauf erreur de ma part). Le mieux n'est-il pas d'encoder le mot de passe côté client avant envoi ?

Déjà, si ton utilisateur est tombé dans le panneau d'une attaque par phishing et a rentré son mdp sur une page qui n'est pas la tienne, ça ne changera strictement rien au fait que le pirate aura son mot de passe en clair et pourra l'utiliser sur ta page. Ou pire, il peut lire le code source de ton JavaScript servant à effectuer le hashage et le reproduira sur sa page d'attaque, ce qui fait qu'il aura le mot de passe et l'utilisateur ne se rendra compte de rien.

La première chose qu'on apprend en sécurité, c'est qu'il ne faut JAMAIS faire confiance au client. Les données malicieuses, intentionnelles ou non, viennent dans 99% des cas du client.
Tu as la main sur le code qui est situé sur ton serveur et si ton application est compromise de l'intérieur, tu es en mesure de réagir. Par contre, tu ne sais pas qui est ton client ni comment il agit car le protocole HTTP fait que tu n'as que les informations qu'il veut bien te donner, et ces informations peuvent de toute façons être falsifiées.

Encoder le mot de passe côté client revient à considérer comme des faits des suppositions impossibles à vérifier, ou alors qui te demanderont de gérer plusieurs cas selon que le mot de passe sera envoyé en clair ou en hashé et donc compliquera inutilement ton travail de développeur :

• Le client est un navigateur utilisant Javascript (adieu les lecteurs optiques pour personnes malvoyantes ou certains terminaux mobiles bas de gamme)
• Javascript est activé (adieu les entreprises où le DSI ou l'admin ou même l'utilisateur lui-même un peu trop paranoïaque a bloqué le JS)

Les seuls moyens suffisamment efficaces à ce jour de se protéger contre les attaques man in the middle sont une connexion sécurisée type SSL et une sensibilisation des utilisateurs aux questions de sécurité des applications web.
Pour rendre ceci encore plus efficace, une authentification forte à 2 facteurs : ajouter au mot de passe un code à usage unique et limité dans le temps envoyé par SMS, par une clé type RSA SecurID ou encore par une application spécifique pour smartphone. Si le voleur a le mot de passe, il n'aura pas l'élément physique nécessaire à l'attaque et pourra difficilement automatiser l'attaque à cause du laps de temps de validité du code.

Mais comme toujours, sécurité et facilité d'utilisation sont généralement antagoniste, et plus on rajoute des couches pour protéger son site, plus on le rend fastidieux à utiliser (et surtout compliqué à maintenir)
Et surtout, aucune sécurité n'est inviolable, car tout programme informatique est contournable, soit par un autre programme, soit par ingénierie sociale.

Je ne suis pas expert en sécurité mais ça veut dire qu'à un moment ou un autre, le serveur est capable de retrouver le mot de passe en clair et je doute que ce soit une bonne chose... non?

Mettons que le propriétaire du serveur en fasse un usage illégal et vole les mots de passe de ses utilisateurs.
S'il veut le voler pour l'utiliser ailleurs (vu que la plupart des gens utilisent le même mot de passe un peu partout, de leur compte facebook à leur banque en ligne) , pourquoi attendre que l'utilisateur retape son mot de passe une nouvelle fois ? Il enregistrera la version en clair dès la création du compte.
S'il veut usurper l'identité d'un utilisateur sur son propre site, il n'a qu'à modifier le mot de passe et lui donner la valeur qu'il veut, et ensuite remettre l'ancien hash à la place, ni vu ni connu.

De toute façons, il faut bien qu'à un moment, le serveur puisse faire la comparaison. Et comme je l'a dit plus haut, le client n'est pas digne de confiance. C'est donc forcément au serveur de s'occuper de rehasher le mot de passe pour pouvoir la faire. Car tu es seul à avoir la main dessus (du moins, en théorie) est tu es donc capable de juger de la confiance que tu peux accorder à ton propre code.

[Neckara]

Je sais qu'il ne fait jamais faire confiance au client, mais dans ce cas là envoyer le hash ou le mot de passe revient au même niveau sécurité.

Pour les spécificités côtés clients hors navigateur utilisés (JavaScript activé ou non, etc.), personnellement je ne m'en occuperais pas (juste mettre un petit message) quitte à perdre une petite partie du public (bon après je ne suis pas professionnel).
Mais rien ne dit que le JavaScript n'est pas obligatoire pour l'utilisation du site ou que le client utilise bien du JavaScript (ex : client en C++).

Mais dans mon raisonnement, je pensais que d'envoyer le hash plutôt que le mot de passe réduit le "moment" où il serait possible (mais très faiblement probable) de retrouver le mot de passe.
De plus comme on ne peut jamais garantir une sécurité à 100%, si jamais une faille est découverte, le mot de passe n'est pas mis en danger.

[gene69]

je me souviens que j'avais écrit un systeme de échange de mdp "sécurisé" (lol) sur du http avec un nomus pour vérifier la formule hash(hash(password) xor nomus) en provenance d'une lib js du client. Pas de mdp stocké en clair, et pas de mdp qui circulent en clair. la sécu s'arrêtait là.

parce qu'envoyer simplement le hash sur le réseau fait que l'on transforme une empreinte avec un super niveau d'entropie en un mot de passe en clair de longueur fixe. on ne doit envoyer que des "transformés" le réseau. Celui qui comprends pas qu'un hash peut être bruteforcé ou rejoué... est une proie.

[X_Cli]

Ce qu'il ne faut pas lire quand même... la cryptographie, ça ne s'improvise pas. Je recommande la lecture de "Applied Cryptography" et de "Secret and Lies" de Schneier pour éviter de raconter des bêtises à ce sujet

MD5 (et encore davantage SHA1) n'ont aucun problème de sécu à ce jour pour ce qui est de leur utilisation pour le hachage de mot de passe. La dernière cryptanalyse dont j'ai science sur les attaques par pré-image (retrouver un antécédant à un condensat) était de l'ordre de 2^123, alors qu'on peine à atteindre (en fait, on en est loin) les 2^100 en terme depuissance de calcul. Ce n'est pas le cas de leur usage lorsqu'il y a risque d'attaques par *collision*, qui est ce jour considéré comme triviales pour MD5.

Hacher le mot de passe coté client est inutile : le secret n'est plus le mot de passe, mais son condensat : apport en capacité d'authentification : zéro-toto. De toutes les manières, si la sécu vous importe sur votre mécanisme d'auth (et elle devrait), utilisez TLS. On peut avoir des certificats pour 0 à 15 euros par an, qui suffisent amplement pour un petit site perso.
Se substituer à TLS est TOUJOURS une mauvaise idée.

Concernant le salt : n'utilisez jamais de sel constant sur plusieurs utilisateurs. Un par user.
Privilégiez des salts vraiment aléatoires (pas rand(om)(), donc). Prévoyez un salt qui complète la taille du bloc de votre algo de hachage, au mini, et mieux un salt qui fasse au moins la taille du bloc (les tailles de blocs sont dispos dans toute bonne doc sur les-dits algo). Idéalement, faites un open de urandom sur les systèmes unix, voire de /dev/random si vous avez un générateur d'entropie à disposition (je ne parle pas de votre femme, messieurs :p) : le PRNG de PHP a été prouvé maintes fois peut fiable : autant l'éviter comme la peste pour la crypto.

"Mais pour qui il se prend, celui là ?" Pour qqn qui fait ça à longueur de journée, de se renseigner, lire et se former pour donner les meilleurs conseils sécu à ses clients