Chiffrement de mot de passe utile ?

Bonjour,
je me demandai après avoir vu plusieurs articles sur la meilleure façon de chiffrer un mot de passe mot de passe si c'est utile.
Car si un pirate arrive à accéder à la table des utilisateurs, il peut également accéder aux informations sur ses utilisateurs (ou clients) .
Modifié par perfectionniste (19 Jun 2012 - 20:30)

Salut,

Le chiffrement ne sert pas a protéger ta BDD, il sert dans un premier temps a ce que le mot de passe ne puisse être utilisé si il est capté en transit et dans un 2eme temps a ce que le pirate ne puisse pas accéder a d'autres comptes (mail, etc...) de l'utilisateur si il utilise le même mot de passe.

pour moi, le meilleur compromis Poids/Sécurité c'est le SHA256, et si tu est pas trop a l'étroit dans ta BDD, SHA512.
Modifié par JJK801 (19 Jun 2012 - 20:33)

Si ton sel est stocké sur le ftp et tes mots de passe dans la base de données alors c'est plus compliqué d'accéder aux deux. En revanche si tu stockes les 2 infos au même endroit, effectivement ça ne sert à rien mais c'est surtout complètement con. Par contre je parle bien de hasher les mots de passe et pas d'utiliser un chiffrement réversible.

jb_gfx a écrit :
En revanche si tu stockes les 2 infos au même endroit, effectivement ça ne sert à rien mais c'est surtout complètement con.

C'est dit odieusement, mais c'est ça

@perfectionniste: pour info, un sel (ou salt) est une chaine de caractères que tu va mélanger au mot de passe avant de la hasher pour le protéger des attaques par dictionnaire:

<?php
$salt = 's1S5f68Q46S6f41D6k';

$hash = hash('SHA256', $_GET['password'].$salt);

C'est une version simplifié du traitement a réellement effectuer bien sur

a écrit :
chiffrer un mot de passe mot de passe

On ne chiffre pas les mots de passe pour les stocker en bdd, on les hashe (on produit une empreinte irréversible)

a écrit :
il sert dans un premier temps a ce que le mot de passe ne puisse être utilisé si il est capté en transit

Là on parle de chiffrement ssl, cad l'établissement d'un canal chiffré entre le client et le serveur.

a écrit :
pour moi, le meilleur compromis Poids/Sécurité c'est le SHA256

Il vaut toujours mieux un mdp hashé avec un algo obsolète qu'un mot de passe stocké en clair.
En revanche, les algos de type md5/sha ne sont pas ceux préconisés actuellment.
On leur préfère bcrypt (voire scrypt), qui a l'avantage d'être lent et dont on peut paramétrer le nombre d'itérations, et donc la durée nécessaire au processus.
La génération de rainbow tables (tables de mdp/hash générées à l'avance permettant de récupérer un mdp grâce à son empreinte) est ainsi considérablement plus longue et la sécurité accrue.

Le salage des mdp est indispensable, cf l'affaire linkedin de la semaine dernière.
Modifié par paolo (19 Jun 2012 - 21:03)

le sel tu le stock dans un fichier texte par exemples ?

Disont que t'arrive à capter un mot de passe envoyer par un utilisateur lors de son inscription , que le mdp soit sallé ou qu'il soit haché qu'estce que ça change , tu a juste a entrer le mdp intersépté.
Modifié par perfectionniste (19 Jun 2012 - 21:17)

@jjk801 Peux tu clarifier ce que tu as écrit par rapport à l'interception du mdp en transit stp ?

Je parle du même principe de ce que protège du SSL en chiffrant les données, si tes données transitent en clair (sans SSL) mais que tu a hashé ton mot de passe avec un salt, le pirate l'a mais ne peut rien en faire. Je pense particulièrement aux transits SQL lors de la connexion a une base de données distante (car c'est pour moi le seul moment ou un mot de passe doit transiter... du site vers la BDD pour comparaison)

ok merci

paolo a écrit :

On ne chiffre pas les mots de passe pour les stocker en bdd, on les hashe (on produit une empreinte irréversible)

Hascher c'est chiffrer.

En toute rigueur non, un chiffrement est réversible, mais c'est courant de ne pas faire le distinguo.
Ceci dit, je parlais de hash, pas de hasch, qui est un domaine dont je ne suis pas expert.

Salut,

perfectionniste a écrit :
Disons que tu arrives à capturer un mot de passe envoyé par un utilisateur lors de son inscription, que le mdp soit sallé ou qu'il soit haché qu'est-ce que ça change, tu as juste à entrer le mdp intercepté.

Tu as tout à fait raison ! Le fond du problème ne concerne pas le hachage du mot de passe avec telle ou telle méthode plus ou moins complexe mais bien de le rendre inexpoitable.

Je rappelle que le mot de passe dans la base de données est haché. Pour le comparer, il faut que le mot de passe que l'utilisateur tape, soit aussi haché. Comme il l'est sur son ordinateur, il faut ensuite l'acheminé via le réseau. La faille est bien le réseau !

Et comme le réseau est chiffrer, donc codage réversible, un hacker connaissant ce chiffrement et passant son temps à écouter le réseau peut cracker n'importe quoi !
Modifié par tournikoti (20 Jun 2012 - 18:36)

tournikoti a écrit :
Et comme le réseau est chiffrer, donc codage réversible, un hacker connaissant ce chiffrement et passant son temps à écouter le réseau peut cracker n'importe quoi !

Quand tu dis que le réseau est chiffré tu parles de quoi ? De SSL ?

paolo a écrit :
En toute rigueur non, un chiffrement est réversible, mais c'est courant de ne pas faire le distinguo.

C'est pas faux.

paolo a écrit :

Ceci dit, je parlais de hash, pas de hasch, qui est un domaine dont je ne suis pas expert.

J'ai ri
Modifié par jb_gfx (20 Jun 2012 - 19:02)

Réseau chiffré avec SSL ?
Se qui veut dire que le SSL est un algo réversible ?

Dans se cas on peut plus rien faire

Sinon pour le hachage, on peut tjrs inventer tout et nimporte quoi pour le rendre plus sur, comme par exemple, remplacer des lettres du mdp par des lettres du pseudo
puis inversser les lettres du mdp, puis le hacher avec hash('sha256', $newMdp) ;

mais ça me parait débile
Modifié par perfectionniste (20 Jun 2012 - 22:10)

Bien sûr que ssl, ou du moins le chiffrement sous-jacent, est réversible. Comment pourrais-tu recevoir et envoyer des données vers un serveur via ssl dans le cas contraire ?

a écrit :
Et comme le réseau est chiffrer, donc codage réversible, un hacker connaissant ce chiffrement et passant son temps à écouter le réseau peut cracker n'importe quoi !

Je n'ai saisi ni la logique ni l'objectif de cette remarque.

a écrit :

Sinon pour le hachage, on peut tjrs inventer tout et nimporte quoi pour le rendre plus sur

Oui on peut, mais c'est une ânerie. Les algos cités ont été cryptanalysés depuis longtemps et à plusieurs reprises. Leurs forces et faiblesses sont connues. A moins d'être un expert de ce domaine, vaut mieux s'en tenir aux bonnes pratiques publiées partout.

L'immense majorité des sites hackés qui font les gros titres étaient négligents sur un aspect (eg: les mdp linkedin n'étaient pas salés)
Modifié par paolo (20 Jun 2012 - 22:21)

Dans le cas pk pas, utiliser une fonction personnalisé de hashage (avec des salts) par jours.
En fonction de la date d'enregistrement on sait qu'elle fonction utiliser pour récupérer le mdp

perfectionniste a écrit :
Dans le cas pk pas, utiliser une fonction personnalisé de hashage (avec des salts) par jours.
En fonction de la date d'enregistrement on sait qu'elle fonction utiliser pour récupérer le mdp

Je pense que tu n'as rien compris de la précédente remarque de Paolo.