.... en clair ?

Captain Obvious, Captain Obvious, Captain Obvious !

Non, mais c'est tout comme.
1. Un message intercepté peut être retransmis pour usurper n'importe quel utilisateur. Sauf si il y a du TLS, bien sûr.
2. En récupérant la base de données, un simple attaque de type dictionnaire suffit pour récupérer plein de mots de passes, vu qu'ils ne sont pas salés.

Moi j'ai compris que :
On hash coté client et coté serveur on vérifie le hash envoyé pas un simple test d'égalité
En clair, si on intercepte la comm, pas besoin du mdp original, seul le hash calculé coté client suffit.

Encore faut-il récupérer la base de données.
Encore faut-il que les mots de passe soient dans le dictionnaire.

Certes, c'est loin d'être la sécurité parfaite, mais entre le clair et ça, ce n'est pas une marge, c'est le gouffre de Helm.

je suis désolé mais non, stocker un mot de passe en clair utilisable tel quel et stocker son hash en SHA512 qui prendra je ne sais combien de temps de brute force afin d'être découvert c'est pas la même chose.

on est d'accords que ca manque de sel tout ça mais ca reste mieux qu'un pass en clair.

de plus sur ce pebkac l'auteur semble penser qu'envoyer le hash au serveur plutôt que le pass en clair est un trou de sécurité béant puisque ce même hash est dans la BDD ?!?

@mini et @Glpl :
Accéder à une base de données, ça arrive souvent. Voir les nombreux scandales du type PSN, LinkedIn, etc. qu'on voit régulièrement.

Une passe de SHA512 prend très, très, très peu de temps. Comme les mots de passes ne semblent pas hachés, on peut commencer avec une table précalculée ou la faire soi-même, ce qui ira très vite pour les mots de passe à 6 ou 7 caractères. En quelques jour on doit sans doute avoir plus de la moitié des mots de passes compromis, ce qui est largement suffisant pour rentabiliser l'attaque.

Sources :
https://crackstation.net/hashing-security.htm
http://www.golubev.com/blog/?p=35

Pour les programmeurs en herbe comme moi, qui aimeraient bien apprendre sans répéter des erreurs comme celles-ici, quelle serait la bonne façon de faire pour
1) empêcher lʼusurpation dʼidentité par quelquʼun qui intercepte les paquets transmis par le client
2) saler le mot de passe. Je veux dire : où est stockée la chaîne de caractères servant au salage, vu que la BDD pourrait être volée ? Pas direct dans le code, quand même.

Pour le point 1), si le canal n'est pas sécurisé on peut déjà utiliser des méthodes de login genre CRAM-MD5 pour éviter de transmettre le mot de passe en clair sur le réseau.

Saler un mot de passe ? Je suis pas un spécialiste, mais je n'en voit pas l'utilité. On sale un hash pour éviter qu'en cas de vol une simple rainbow table suffise à retrouver des mots de passes valides.

Bah c'est juste qu'ai lieu de coder le pass en clair, ils codent son hash en clair... Hash envoyé directement par le client.
Du coup, si on a accès à la BDD, il suffit d'envoyer le hash, et terminé, on a accès au compte. Cela revient strictement au même que de stocker le pass en clair.

En fait, du point de vue du serveur, le hash est juste la même chose qu'un mot de passe, sauf qu'il n'est pas entré directement par l'utilisateur... Ce qui ne change absolument rien du point de vue du serveur.

Si un mot de passe stocké en clair est un PEBKAC, alors ceci l'est tout autant.

Ca manque de sel peut etre mais du moment qu'on connait la fonction de hashage peut importe que le hash soit fait coté client ou coté serveur. Dans un cas comme dans l'autre c'est facile de trouver ce qu'il faut envoyer au serveur.

@Luciole. Si, dans le code semble être le plus logique (ou dans un fichier de configuration mais ca revient au meme). Pour empécher l'interception de packet par contre il va falloir passer par du https et encore....

"Encore faut-il récupérer la base de données.
Encore faut-il que les mots de passe soient dans le dictionnaire."

Si le serveur reçoit un hash du passwd, t'as juste besoin de connaitre le hash pour te connecter. La vesion clair du mot de pass est inutilisée du coup.

PEBKAC

2) Les sels sont stockés dans la base de données. Quand tu crées un utilisateur, tu généres un sel aléatoirement. Plutôt que de simplement hasher le mot de passe et le stocker dans la base, tu hash la combinaison du sel et du mot de passe, que tu stockes dans la base. Lorsque tu veux vérifier le mot de passe, tu prend le sel de l'utilisateur en question, tu le combines avec le mot de passe envoyé par l'utilisateur et tu hash. Si ca correspond à ce que tu as dans ta base, le mot de passe est bon, sinon problème d'authentification.

Tu arrives à obtenir une BDD sans sel: T'as une rainbow table, tu testes tout sur toute ta base => tu trouves plein de mots de passe. Si tu trouves que le hash XYZ correspond au mot de passe 'password'. Alors tu sais que tous les utilisateurs dans la base ayant un hash à XYZ ont le mot de passe 'password'.

Tu arrives à obtenir une BDD avec sel: Ton test de rainbow table ne va probablement pas donner grand chose (sauf cas rare, genre, le mot de passe est 'ssword' et le sel généré donne en ascii 'pa'). En effet, ta rainbow table contient le hash correspondant à 'password' mais probablement pas le hash correspondant à '/x25/x89password' (si le sel est 0x2589). Pour chaque utilisateur (ou pour chaque groupe d'utilisateurs ayant le même sel), tu vas devoir avoir les hashs de tous les passwords dans ta rainbow table AVEC le sel... ou bien faire du brute force...

Donc oui, le sel est stocké dans la base de données, et ce n'est pas un problème. C'est mieux si les sels restent secrets mais ce ne sont pas non plus des clés privées...

Au niveau du code, tu peux aussi avoir une info constante que tu vas ajouter à tous les mots de passe (et sels) avant de hasher, on appelle ça un poivre.
Si tu te fais voler la base de données, le hacker aura les hashs, les sels mais pas le poivre... (bon après, il est fort possible qu'en arrivant à hacker la BDD, il soit aussi en mesure de hacker le reste et de récupérer ton exécutable/script et obtenir le poivre... mais c'est pas sûr non plus, tout dépend de l'architecture du/des serveur(s))

Ca pourrait être pire, il aurait pu proposer un ROT13 ;-)

Comme le dit Freud, si l'encodage (hashage) est fait côté client, on compare au niveau serveur ce qui existe en base et ce qui est envoyé (même avec un coup de base64 qui se reconnait vite).
Bref, les mots de passe seraient en clair dans la base et envoyés tel quel, ce serait pareil.

Donc, énorme PEBKAC.

Toutes les solutions d'annuaire, libre ou microsoft prévoient le stockage de mot de passe sous forme hashée avec ou sans sel (c'est une fonction du produit, ce n'est pas un PEBKAC). Sans sel est une fonction par défaut d'ailleurs.

Vous êtes tous entrain de parler de Rainbow Tables mais il faut la base pour que cela serve. Ce n'est pas à la portée du premier venu, donc ce n'est pas un PEBKAC. De plus avec une bonne politique de choix de mot de passe, les Rainbow Tables Charset 8bits 8+ caractères, cela ne court pas les rues.

Enfin rien ne dit ici que la com Client/Front WEB et/ou Middle WEB/Annuaire n'est pas chiffrée...

Pour moi, ici le seul PEBKAC, c'est "Côté client, faire..." je ne vois pas l'intérêt...