Plusieurs post récents m'ont donné l'idée d'ouvrir un fil sur le sujet du hachage/cryptage des mots de passe.

Pour rappel:

• Le hachage est réputé inviolable mais irréversible ce qui peut être gênant pour renvoyer un mot de passe oublié par exemple. PHP offre deux fonctions de hachage: md5() sha1().
• Le cryptage est réversible grâce à l'utilisation d'une clé secrète. PHP dispose d’une bibliothèque très complète pour crypter décrypter ce qu'on veut (mcrypt).

Personnellement, j’utilise le cryptage avec une clé secrète complexe pour générer des mots de passe. Si l'utilisateur le perd, on peut le lui renvoyer sans devoir lui en attribuer un nouveau.

Les hachages sha1() ou md5() sont réputés plus sécurisés mais réfléchissons un instant: un utilisateur choisi son mdp, l'envoie, en clair dans la plupart des cas, par formulaire. Sur le serveur on le stocke en bdd, haché en md5 ou sha1. D'accord c'est quasiment indéchiffrable pour un pirate (quoique...). Mais si on prend le soin de le hacher en bdd, c'est qu'on craint qu'il accède à la bdd et qu'il puisse y lire tous les mdp.

Maintenant, soyons réalistes, s'il accède à la bdd, il y a de grandes chances qu'il puisse y faire également tout ce qu'il veut! Il n'a plus besoin des mdp!

OK, il y a le cas du piratage par injection d'un SELECT sur la table des mdp. Il reçoit, en retour, la liste des mdp hachés. Il n'a pas accès à la bdd mais il a les mdp. Maintenant haché ou crypté...

S'il est motivé pour décrypter, il réussira sans doute très bientôt à dé-hacher md5 ou sha1. C'est une question de temps.
http://www.cryptography.com/cnews/hash.html

Solutions:

• formulaire de mot de passe et de login en SSL
• mot de passe stocké en md5 sha1 ou crypté avec une bonne clé secrète.
• protéger tous ses formulaires et bdd contre l'injection SQL

Même si la sécurité ne se limite pas à ces trois points, loin s’en faut, ils sont indispensables pour protéger les mots de passe des sites sensibles.

Maintenant, concernant le choix entre hachage et cryptage songez que beaucoup de sites « pro » sont capables de régénérer un mot de passe oublié. Ils utilisent donc le cryptage, pas le hachage.

Les protocoles SSL et SSH ou le standard PGP (Pretty Good Privacy), pour ne parler que des plus connus, utilisent également des techniques de cryptage/dé-cryptage (symétriques ou asymétriques).

Voilà, PHP permet d’utiliser les deux très facilement.

Faites votre choix !

En cas d'intrusion d'un *bon* pirate, il peut récupérer toutes les données ainsi que les codes sources. Que les mots de passe soient cryptés ou en clair c'est alors kif-kif. Qu'il obtienne les mots de passe ne constitue pas un trou de sécurité pour le site (le pirate est déjà entré, le site est mort) mais pour les utilisateurs : en effet le pirate obtient des couples email/password qu'il peut alors essayer tranquillement pour accéder aux boites mails des utilisateurs (qui souvent utilisent le même mot de passe partout) et ainsi découvrir divers autres services (accès au compte en banque, etc...).

Comme en PHP on a rarement la main sur la sécurité du serveur (firewall en amont, failles du serveur patchées ou non, etc...) je considère qu'il vaut mieux partir du principe que le pirate qui entre et fait ce qu'il veut existe, et qu'il faut donc prémunir les utilisateurs contre l'effet boule de neige potentiel.

Maintenant on est d'accord qu'en cas de piratage "classique" par sql-injection ou par intrusion UNIQUEMENT dans la base de données, cryptage et hashage sont tout autant sécurisés.

Une chose est important également c'est de comprendre que tant que la connexion au site n'est pas sécurisée (https), les données sont envoyées en clair, et un sniffer quelconque récupèrera donc les mots de passe qui transitent sans problème. L'https est lourd à mettre en place, ou souvent cher chez l'hébergeur, mais si vous voulez réellement sécuriser (et faire les choses bien) l'identification le plus efficace est de le faire en amont avec un transit des données qui soit crypté par SSL avant même de se poser la question du stockage en bdd

Solutions:

• formulaire de mot de passe et de login en SSL
• mot de passe stocké en md5 sha1 ou crypté avec une bonne clé secrète.
• protéger tous ses formulaires et bdd contre l'injection SQL

J'ajouterais :

• Sécurisation du serveur

mais ce n'est pas donné à tout le monde d'avoir accès au firewall (obligatoirement doté d'un IPS) en amont, de pouvoir patcher son serveur et le firewall, de pouvoir disposer des toutes dernières versions de chaque logiciel, et de pouvoir faire la veille technologique nécessaire pour être au courant des failles et des patches quasiment en temps réel (et de pouvoir le cas échéant écrire ses propres règles snort en attendant les mises à jour de l'IPS). Tout ceci pour éviter une intrusion catastrophique comme je l'ai citée.

Et ne pensez pas que ça n'arrive pas, chaque jour dans les salles blanche du monde entier des serveurs sont violés, et personne n'en parle

La différence entre md5 et sha1 est que md5 est une fonction injective non bijective. On ne peut pas retrouver le mot de passe originel; on peut au mieux (avec une probabilité presque nulle) trouver un mot ayant la même empreinte. Pour sha1, il suffit de connaitre la clé privé pour avoir accès à tous les mots de passe.
Pas d'hésitation entre md5 et sha1 je choisis md5.

La différence entre md5 et sha1 est que md5 est une fonction injective non bijective. On ne peut pas retrouver le mot de passe originel; on peut au mieux (avec une probabilité presque nulle) trouver un mot ayant la même empreinte. Pour sha1, il suffit de connaitre la clé privé pour avoir accès à tous les mots de passe.
Pas d'hésitation entre md5 et sha1 je choisis md5.

Dans mes souvenirs sha1 est une fonction de hashage, donc injective, et je n'ai jamais entendu parler de "clé" dans l'algo de sha1
Tu ne voulais pas dire "la différence entre md5 et mcrypt" ?

Et ne pensez pas que ça n'arrive pas, chaque jour dans les salles blanche du monde entier des serveurs sont violés, et personne n'en parle

(desole pour les accents, je poste sur un clavier qwerty norvegien!)

Ces actes de piratages sont souvent le fait d employes qui ont un acces physique aux serveurs ou au reseau ip. Comment mettre en place sinon un analyseur de trame? Je n imagine pas un pirate, installant des pinces croco sur un cable telephonique, decoder le signal dsl et analyser les trames.

Par contre, en entreprise, c est a la portee du premier bidouilleur venu. De plus en plus d intranet utilisent d ailleurs SSL avec certificats auto-signes pour proteger les communications http.

Il existe tellement de types d attaques possibles, et tellement de parades que la securite est un metier a part entiere. Hautement specialise.

Tout ce qu on peut faire a notre niveau, c est de prendre un minimum de precautions elementaires. Faut pas etre parano mais ne pas l etre du tout est inconscient.

Quant aux collisions SHA-0 trouvees par des chercheurs francais (chercher Antoine Joux sur google), faut relativiser, il ont quand meme eu besoin de 80000 heures de CPU d un super calculateur Bull pour y arriver!

Bon j arrete, ce clavier me rend føu!

Je n imagine pas un pirate, installant des pinces croco sur un cable telephonique, decoder le signal dsl et analyser les trames.

@ripat detrompe toi, je pense qu'ils le font, ils sont capables de beaucoup plus : du social engeneering à la fouille de poubelle.

oui, les collisions qu'on a trouve pour l'instant sont sur des versions faibles des algos, et sont des collisions donnees, cad 2 mots particuliers qui ont la meme empreinte. mais ca ne signifie pas du tout qu'etant donne une empreinte, on sache trouver un mot qui genere cette empreinte. la nuance est primordiale.

ensuite, utiliser un cryptage a cle prive pour les mdp, je trouve ca craignos, quand meme : si c'est automatique, c'est que la cle est qqpart dans le code source !! c'est pas prudent. je penses qu'en matiere de cryptage il ne faut pas se donner plus de liberte que necessaire. un mot de passe n'a pas besoin d'etre decrypte pour fonctionnner ? alors on utilise un cryptage a sens unique, point. rien que le fait que ce soit possible de recuperer la cle, meme si c'est difficile, est un point faible qui n'est pas necessaire, donc autant le supprimer.

pour les plus parano, il suffit d'implementer SHA-256 qui vous grantit une securite absolue. mais le sha-1 fait parfaitement l'affaire, et sauf ordinateur secret dans les caves du NSA, personnes aujourd'hui ne saurait retrouver vos mdp en moins de quelques millenaires pour peu qu'ils soient assez long ! car je penses que le point faible principal est la. quelque soit le cryptage utilise, si le mot de passe n'a que 4 caractere, on pourra le retrouver. avec le haschage, il n'ya pas de limitations de taille maximale, vu que l'empreinte fait tjrs la meme taille. donc autorisez, recommandez ou imposez des mots de passe long, voila ma recommandation du jour

tant qu'a faire, je pose une question : peut on creer une connection SSL sans etre enregistre aupres d'une instance qui donne des certificats ? du coup on ne serait pas authentifie, mais la connection serait secure ( et c'est la seule chose qui m'interresse ).

...en moins de quelques millenaires pour peu qu'ils soient assez long !....

Aux dernières nouvelles, un millénaire devrait, si la tendance se maintient, durer mille ans

Je suis déjà parti

...en moins de quelques millenaires pour peu qu'ils soient assez long !....

Aux dernières nouvelles, un millénaire devrait, si la tendance se maintient, durer mille ans

oh ! tu sais, tout fout le camp, tout va plus vite, alors, je n'en suis pas si sur. et puis, un millenaire, c'est pas 1024 ans ?

Je suis déjà parti

attends, j'arrive ..

tant qu'a faire, je pose une question : peut on creer une connection SSL sans etre enregistre aupres d'une instance qui donne des certificats ? du coup on ne serait pas authentifie, mais la connection serait secure ( et c'est la seule chose qui m'interresse ).

Bien sûr, la seule différence entre un https certifié par un tiers certificateur et un autre certifié par rien du tout, c'est que le second fera afficher au navigateur un avertissement de sécurité "le certificat ne peut être vérifié", mais la qualité du cryptage est exactement la même. Par contre le certificat ne garantit pas l'identité du site (puisqu'il n'est pas certifié par un tiers).

oui, c'est ce que je disais, la grosse question c'est comment je fais ?? je suppose qu'il faut que je cree un certificat, je sais qu'open ssl est installe chez mon hebergeur, mais je ne sais pas si pour autant c'est prevu qu'on utilise des https. qqn aurait il une idee de la marche a suivre ?