8791 sujets

Développement web côté serveur, CMS

Bonjour à tous,

Je suis novice dans le php et mysql, et j'entame l’administration de l'espace client du site de mon beau frère.

Je lis ici et là, des choses sur la manière de protéger le mot de passe d'un utilisateur en base de données.

J'ai notamment lu que le md5 n'était plus trop à privilégier, et qu'à la limite, il devenait un peu plus sécurisé en le "salant". Le sha1 est à peu près préconisé sur tout ce que j'ai lu.

Moi et ma petite tête de débutant, on s'est réunis, et on s'est posé la question suivante :

Et si je faisais le md5 d'un sha1 ?
ou encore, le md5 d'un sha1 d'un md5 d'un sh1 ?
etc...

qu'en pensez vous?
Est-ce une solution plus sur?

Personnellement, avant de savoir le nombre de fois que le hash md5 ou sha1 a été fait, l'utilisateur malintentionné n'est pas près d'arriver à ses fins. Mais je raconte peut-être des bêtises.

A vos claviers, et merci beaucoup d'avance. Smiley smile
Salut Smiley smile

pas fan des algo de cryptage j'ai pour ma part créé le mien Smiley cligne totalement indéchiffrable si on connait pas la méthode Smiley smile

masi moi je peux décrypter Smiley cligne

bon sinon, j'ai regardé duc oup suite à ta question et une nouvelle paire de fonctions fait son apparition

password_hash()

et

password_verify()

ça semble assez sécure comme truc Smiley cligne

mais il faut que ta version de php soit capable de l'utiliser Smiley smile
Bonsoir,
Merci pour ces petites trouvailles, qui complèterons certainement ce sujet.

Je reste dans l'attente d'avis sur la méthode de "multi hash". Smiley smile

Cordialement.
Modérateur
Bonjour
Alexbass a écrit :

J'ai notamment lu que le md5 n'était plus trop à privilégier, et qu'à la limite, il devenait un peu plus sécurisé en le "salant". Le sha1 est à peu près préconisé sur tout ce que j'ai lu.

Pour être précis: Le md5 est définitivement à oublier pour de la sécurité, car il est devenu trop facile à attaquer. Pour le sha-1, il est en phase d'abandon. En effet une vulnérabilité est prouvée, cependant la meilleure attaque connue pour l'heure est estimée à un coût de 2,7 millions de dollars en calcul de machines pour obtenir une collision d'un hash sha-1. Mais vu que la vulnérabilité est prouvée, les temps et moyens nécessaires pour «casser» du sha-1 devraient fortement baisser dans les années à venir.
Aujourd'hui on préconise donc au moins le sha-2 pour les nouveaux systèmes.

Pour le multi-hash: effectuer par exemple md5(md5()) ne revient au final qu'à doubler le temps de calcul, en augmentant même un peu le risque de collisions. Pour les attaques par dictionnaire, ça peut éventuellement servir de sel «statique» mais ne vaut pas un vrai sel.

a écrit :
Personnellement, avant de savoir le nombre de fois que le hash md5 ou sha1 a été fait, l'utilisateur malintentionné n'est pas près d'arriver à ses fins.

Si la base de donnée est compromise, il y a de grande chances que le code le soit aussi. La méthode utilisée est un secret de polichinelle.

pchlj a écrit :
pas fan des algo de cryptage j'ai pour ma part créé le mien Smiley cligne totalement indéchiffrable si on connait pas la méthode Smiley smile

masi moi je peux décrypter Smiley cligne

Déjà ce n'est pas du chiffrement mais du hashage. La différence énorme est que le but du hashage, est que même le développeur ne peut retrouver le mot de passe.
Votre méthode est à proscrire et n'offre pas la moindre sécurité: 1) comme dit plus haut, la méthode peut être connue, 2) même l'administrateur de la base de donnée n'a pas à connaitre les vrais mot de passes.

Effectivement, il faut utiliser password_hash ou, à défaut, crypt avec un salage.
En effet kusto... l'administrateur ne connait pas les mots de passes

pour revenir sur le Hashage ou cryptage

dixit wikipedia :

a écrit :
Le chiffrement ou cryptage est un procédé de cryptographie grâce auquel on souhaite rendre la compréhension d'un document impossible à toute personne qui n'a pas la clé de (dé)chiffrement.


et MA solution est bien une solution de cryptage.. qui comme tout cryptage s doit de pouvoir être décrypté... comment ils feraient pendant les guerres si ils n'arrivent pas à décrypter un message crypté ???

donc là on parle de hashage... car un hashage n'est en effet pas décryptable (enfin normalement)

on ne peux donc que comparer que 2 hashage sont équivalent ce qui prouve qu'il s'agit de la meme valeur.

Ce que font les deux nouvelles fonctions PHP

après c'est un choix... soi ton hash par divers procédés et on en connait jamais la valeur originale, on en peut que comparer.

Soit on crypte avec donc une possibilité de décrypter.

pour les mots de passe le hashage est plus que recommandé car c'est le plus sécure.

Un cryptage bien fait peut être tout aussi sécure Smiley cligne

Sur le point que tu soulève...
a écrit :
Si la base de donnée est compromise, il y a de grande chances que le code le soit aussi. La méthode utilisée est un secret de polichinelle.


Oui et non pas forcément... il est "facile" de faire de l'injection sql pour voir les bdds mais cela ne donne pas accès au code pour autant Smiley smile donc la méthode n'est pas forcément connue Smiley cligne

En tous cas sécurisé au maximum et son code et sa bdd sont des bases de dev Smiley cligne

Pour ma part je travaille sur des sites qui sont PCI/SAAS et crois moi que la marge d'erreur est très très faible.
Pour revenir au sujet de départ...

Il n'y a pas de MEILLEURE solution..

privilégie la plus récente qui possède le plus de sécurité, car la plus récente s'appuie sur les erreurs des plus anciennes.
après tu peux haché un crypt qui lui meme crypt un hachage... bref fait autant de tour que tu veux.

comme le dit kusto ça ne fera que ralentir si ce sont des méthodes anciennes et connues
Modérateur
pchlj a écrit :

après c'est un choix... soi ton hash par divers procédés et on en connait jamais la valeur originale, on en peut que comparer.

Soit on crypte avec donc une possibilité de décrypter.

pour les mots de passe le hashage est plus que recommandé car c'est le plus sécure.

Un cryptage bien fait peut être tout aussi sécure Smiley cligne

Non. Tu fais ce que tu veux avec tes propres mots de passes. Les mots de passe de tes utilisateurs doivent être hashés, un point c'est tout. Le chiffrement est forcément moins sûr. Son utilisation doit être réservée aux cas où on a absolument besoin de retrouver la donnée déchiffrer. Comme les seules raisons de faire cela pour les mots de passe sont absolument illégitimes, on utilise des hash.

pchlj a écrit :
Oui et non pas forcément... il est "facile" de faire de l'injection sql pour voir les bdds mais cela ne donne pas accès au code pour autant Smiley smile donc la méthode n'est pas forcément connue Smiley cligne

L'injection SQL n'est qu'une des méthodes, et peut facilement permettre de lire des fichiers. De plus, les risques viennent aussi de la part des personnes ayant un accès légitime au code et à la base de donnée. (Généralement les gens ayant accès au code sont plus nombreux, donc c'est encore pire).
a écrit :
Oui et non pas forcément... il est "facile" de faire de l'injection sql pour voir les bdds mais cela ne donne pas accès au code pour autant
donc la méthode n'est pas forcément connue


IL y a une règle très importante en cryptographie qui dit que la sécurité d'un achage ou d'un cryptage ne doit jamais se reposer sur le fait que l'algorithme est secret.

Les bonnes méthodes sont sûres mêmes si le code source est connu. D'ailleurs sauf erreur les sources permettant d'encoder/décoter/hasher avec AES ou sha sont disponibles. Si tu te bases sur le secret de la méthode, le jour où on découvre ton code, tu as tout perdu. et inventer son propre truc révolutionnaire en général ça ne marche pas, sauf si on est spécialiste et qu'on est capable de prouver qu'on ne peut pas faire mieux que de la brute-force pour casser le code.
Perso je crypt en BlowFish :

function Blowfish_Decrypt($data, $KeyBlowFish){
	$iv = pack("H*" , substr($data, 0, 16));
	$x = pack("H*" , substr($data, 16)); 
	$res = mcrypt_decrypt(MCRYPT_BLOWFISH, $KeyBlowFish, $x , MCRYPT_MODE_CBC, $iv);
	$res = preg_replace('/[^(\x20-\x7F)]*/', '', $res);
	return $res;
}

function Blowfish_Encrypt($data, $KeyBlowFish){
	$iv_size = mcrypt_get_iv_size(MCRYPT_BLOWFISH, MCRYPT_MODE_CBC);
	$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
	$crypttext = mcrypt_encrypt(MCRYPT_BLOWFISH, $KeyBlowFish, $data, MCRYPT_MODE_CBC, $iv);
	return bin2hex($iv . $crypttext);
}

$salt = "abc123";
$text = "Message secret !";

$text_crypt = Blowfish_Encrypt($text, $salt);
$text_decrypt = Blowfish_Decrypt($text_crypt, $salt);

echo $text_crypt;
echo "<br>";
echo $text_decrypt;


Après j'avoue que je suis pas un expert (clairement !!!!), mais c'est pas mal comme cryptage.
bonjour à tous,

Je vous remercie pour vos explications et conseils.

Du coup j'ai un peu lu le manuel php sur password_hash et password_verify.

ôtez moi d'un doute :

// exemple sur php.net
$hash = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a';
if (password_verify('rasmuslerdorf', $hash)) {
    echo 'Le mot de passe est valide !';
} else {
    echo 'Le mot de passe est invalide.';
}

est bien égale à

$mdp_utilisateur = password_hash("rasmuslerdorf", PASSWORD_DEFAULT); //->Ici, la valeur transmise par le formulaire, validé par l'utilisateur.
$hash = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a'; //-> Ici la valeur stocker en bdd.
if ($mdp_utilisateur === $hash)  {
    echo 'Le mot de passe est valide !';
} else {
    echo 'Le mot de passe est invalide.';
}

Ou bien je suis à l'ouest et je n'ai rein compris? Smiley smile
Alexbass a écrit :
bonjour à tous,

Je vous remercie pour vos explications et conseils.

Du coup j'ai un peu lu le manuel php sur password_hash et password_verify.

ôtez moi d'un doute :

// exemple sur php.net
$hash = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a';
if (password_verify('rasmuslerdorf', $hash)) {
    echo 'Le mot de passe est valide !';
} else {
    echo 'Le mot de passe est invalide.';
}

est bien égale à

$mdp_utilisateur = password_hash(&quot;rasmuslerdorf&quot;, PASSWORD_DEFAULT); //-&gt;Ici, la valeur transmise par le formulaire, validé par l'utilisateur.
$hash = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a'; //-&gt; Ici la valeur stocker en bdd.
if ($mdp_utilisateur === $hash)  {
    echo 'Le mot de passe est valide !';
} else {
    echo 'Le mot de passe est invalide.';
}

Ou bien je suis à l'ouest et je n'ai rein compris? Smiley smile


Non, si tu régénères un hash du mot de passe tu obtiendras un résultat différent (parce que le sel généré par password_hash() est une valeur aléatoire). Tu dois utiliser password_verify() comme indiqué dans les exemples de la doc.

Note aussi que si tu décides d'utiliser la valeur PASSWORD_DEFAULT pour désigner l'algorithme utilisé par l'API, alors tu dois obligatoirement mettre en place un système de mise à jour du hash en utilisant la fonction password_need_rehash(). Car PASSWORD_DEFAULT est une valeur qui est destinée à évoluer dans le futur et si tu ne l'utilises pas correctement tu risques de retrouver ta fonction de connexion cassée suite à une simple mise à jour de PHP.

kustolovic a écrit :

Non. Tu fais ce que tu veux avec tes propres mots de passes. Les mots de passe de tes utilisateurs doivent être hashés, un point c'est tout. Le chiffrement est forcément moins sûr. Son utilisation doit être réservée aux cas où on a absolument besoin de retrouver la donnée déchiffrer. Comme les seules raisons de faire cela pour les mots de passe sont absolument illégitimes, on utilise des hash.


+1

Mais plutôt qu'un "hash" générique, une fonction de hachage conçue spécifiquement pour les mots de passe : scrypt, PBKDF, bcrypt... . Les algorithmes de hachage génériques n'ont pas été conçu pour ça. On les a utilisé, tel quel, à une époque parce qu'on n'avait pas mieux.

D'ailleurs il y a une compétition en ce moment pour désigner un nouvel algorithme et dont les résultats seront dévoilés à la mi 2015.

A voir ici : https://password-hashing.net/

QuentinC a écrit :
[
IL y a une règle très importante en cryptographie qui dit que la sécurité d'un hachage ou d'un cryptage ne doit jamais se reposer sur le fait que l'algorithme est secret.


+1

Ça ne vaut pas que pour les algos de hachage mais pour a peu prês tous les systèmes utilisés dans le domaine de la sécurité.

pchlj a écrit :
*


-50000

Tout ce que dis n'es pas, non seulement faux, c'est aussi dangereux !

Modifié par LaJota (15 Dec 2014 - 10:21)
bonjour Lajota.

Je te remercie vivement des tes explications.

Est-ce qu'il est normal, que dans le hash récupéré, on retrouve le type de cryptage (si j'ai bien compris), ainsi que le coût ? ($2y -> pour BCRYPT et $12 -> pour le coût)

<?php
/**
 * Dans ce cas, nous souhaitons augmenter le "cost" par défaut pour BCRYPT à la valeur 12.
 * Notez que nous passons également à l'algorithme BCRYPT, qui produit toujours un résultat
 * de 60 caractères.
 */

$options = [
    'cost' => 12,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options)."\n";
?>
Le résultat : $2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K
Sur certain forum, certains disent qu'il y a donc un risque de trouver la méthode et le mot de passe.

A quel moment le salt est généré ? Par PASSWORD_BCYRPT ? (salage + hash) ?

Si j'ai bien compris, PASSWORD_VERIFY, trouve lui même le salt qui avait été généré, et trouve lui même la méthode utilisée? (BCRYPT ou DEFAULT) ?

Je pense que je vais utiliser l'exemple avec PASSWORD_BCRYPT (même si je n'ai pas toutes les subtilités de la machinerie invisible), Par contre, j'aimerais savoir quelles devront être les propriétés de ma colonne en SQL pour stocker ces mots de passe "hashés". (Je voulais faire un jeu de mot avec steak haché, mais j'ai pas trouvé. C'est peut être mieux ainsi Smiley smile )

Par avance, je vous remercie énormément.
Alexbass a écrit :

Est-ce qu'il est normal, que dans le hash récupéré, on retrouve le type de cryptage (si j'ai bien compris), ainsi que le coût ? ($2y -&gt; pour BCRYPT et $12 -&gt; pour le coût)


Oui, tu as très bien compris. Quand tu utilises l'API password de PHP elle te génères une chaîne qui donne l'algorithme, le coût, le sel et le hash.

Alexbass a écrit :

A quel moment le salt est généré ? Par PASSWORD_BCYRPT ? (salage + hash) ?


Ça n'a pas vraiment d'importance de savoir "à quel moment' le sel est généré. Ce qui est important, si tu t'intéresses à la théorie c'est de comprendre pourquoi.

Alexbass a écrit :

Si j'ai bien compris, PASSWORD_VERIFY, trouve lui même le salt qui avait été généré, et trouve lui même la méthode utilisée? (BCRYPT ou DEFAULT) ?


La fonction password_verify() prends la clé stockée en base de données, la découpe, et en ressort les informations utiles pour régénérer le même hash depuis le mot de passe que l'utilisateur fournit au moment de la connexion.

Alexbass a écrit :

Je pense que je vais utiliser l'exemple avec PASSWORD_BCRYPT (même si je n'ai pas toutes les subtilités de la machinerie invisible)


Oui, c'est une bonne idée si tu débutes. Concentres toi sur l'essentiel et tu verras les subtilité par la suite. Pour le moment on parle juste de stocker le mot de passe de l'admin pour ton beau-frère, c'est pas la peine de se prendre pour le roi de la crypto et d'essayer d'inventer la roue crevée. Smiley smile

Alexbass a écrit :

Par contre, j'aimerais savoir quelles devront être les propriétés de ma colonne en SQL pour stocker ces mots de passe &quot;hashés&quot;. (Je voulais faire un jeu de mot avec steak haché, mais j'ai pas trouvé. C'est peut être mieux ainsi Smiley smile )


La doc stipule que la valeur idéale pour la colonne est un varchar de taille 255.

a écrit :

Sur certain forum, certains disent qu'il y a donc un risque de trouver la méthode et le mot de passe.


Bienvenue dans le monde de la pseudo-science. Smiley smile Quand tu tombes sur ce genre d'affirmation essaye de voir si la personne en face de toi peut t'apporter une preuve de ce qu'elle clame. Si tu n'obtiens pas de réponses satisfaisante, ou si, dans le cas de la sécurité, tu tombes sur un métalleux qui a un pote qui s'appelle LeetoPirator666 qui lui a dit que : passes ton chemin. Smiley cligne

Je reviendrais poster un truc sur la théorie et les mécanismes derrière tout ça tout à l'heure ou demain vu que le sujet à l'air de t'intéresser.
Merci beaucoup pour ton aide.

Il y a en effet, le mot de passe de mon beau-frère pour l'administration.
Il y a aussi les mots de passe de ses clients... c'est surtout pour ça que je ne veux rien louper Smiley smile

Ps : Je vais poster un autre sujet, car je bloque sur des conditions. (j'ai une variable qui devrait passer à true, et elle n'y passe pas. Smiley decu )