Discussion :

[StringBuilder]

Bonjour,

Lorsque j'ai commencé à travailler sur des sites internet, en 1999, la sécurité était loin d'être le point le plus épineux, et les outils à disposition étaient bien moins avancés qu'actuellement : pas de LDAP, pas de possibilité de crypter un mot de passe depuis la base de données, pas de libs existantes en PHP ou ASP, etc.

Du coup, j'ai pris l'habitude de stocker dans mes tables "utilisateur" le mot de passe en claire.

Régulièrement, je vois des personnes, à la limite de l'intégrisme, ne jurer que par un cryptage MD5 du mot de passe dans la base.

Et là, je bloque.

En effet, lorsqu'on stock le mot de passe de façon crytée, le seul avantage que je vois, c'est qu'on ne connait plus le mot de passe "tel qu'il est saisi par l'utilisateur".
Mais si le mot de passe crypté fuite, le risque d'utilisation de la signature MD5 reste entier... Sans parler d'un simple brute force sur cette signature, qui permettra en quelques minutes, au pire quelques heures, de retrouver le mot de passe original.

De ce fait, je ne vois pas bien en quoi c'est tellement mieux que de stocker le mot de passe en clair.

Je me pose cette question surtout car je vois très souvent des personnes partir du principe que le mot de passe est crypté, ne vont pas chercher à protéger la table de quelque que façon que ce soit.
Habituellement, je fais un certain nombre d'actions au niveau de la base de données de façon à ne pouvoir en aucun cas accéder au champ mot de passe par requête :
- Suppression des droits de lecture et autres sur la colonne mot de passe, voir de toute la table, pour tous les utilisateurs
- Création de procédures/fonctions stockées CheckPassword(login, password), SetPassword(login, oldpwd, newpwd) etc. qui seront les seules façon d'accéder à cette colonne. En aucun cas ces fonction ne retourneront la valeur

=> A quoi ça servira de rajouter une encryption ?

Cordialement,
Sylvain Devidal

[Oishiiii]

MD5 n'est pas la seule méthode de hashage. Il y en existe des plus "sécurisantes"; les SHA-2 par exemple.

Ce sont des méthodes de hash et non "d'encryption". Le hash n'est pas reversible, décryptable.

Pour éviter la bête attaque par dictionnaire il suffit d'utiliser un grain de sel au moment de la création du hash.
Je n'ai pas vérifier récemment mais il me semble que c'est tout de même très long le "brut force" sur un hash sha-2.

Certes vous utilisez des fonctions et procédures stockées, mais les mots de passes sont tout de même envoyés au SGBD en clair, sur le réseau.
Il n'est pas difficile de scanner les packets TCP sur le port qui est souvent par défaut le 1433 et retrouver ces mots de passes....

De plus avec un stockage des MDP en clair, ce n'est pas seulement la table SQL qu'il faut sécuriser. Mais toute votre méthode de sauvegarde (et restauration?), puisqu'il suffit de récupérer un fichier de sauvegarde pour accéder aux mots de passe.

[StringBuilder]

Habituellement, on utilise une connexion sécurisée entre le serveur web et le serveur de base de données, donc non, le mot de passe ne circule pas en claire.

Un bon point pour la sauvegarde. Je n'y avait pas pensé. Mais je trouve ça maigre.

Ceci dit, je pense qu'à l'avenir, je passerai par une phase d'encryption du mot de passe (qui peut le plus peu le moins)... Sans pour autant être bien convaincu
Je pense que les autres éléments de sécurisation sont bien plus importants.

[SQLpro]

Régulièrement, je vois des personnes, à la limite de l'intégrisme, ne jurer que par un cryptage MD5 du mot de passe dans la base.

MD5 et tous les algorithmes de hachage (MD2, MD4, MD5, SHA, SHA1) ne sont ABSOLUMENT PAS des méthodes de cryptage, malgré que quelques produits commerciaux pour demeurés les présentent ainsi, parce ces produits sont incapable de mettre en œuvre une véritable cryptographie.

En effet, il faut pas plus de 5 minutes pour trouver par force brute, les quelques centaines de littéraux correspondant à une clef de hachage....

En revanche voici quelques algorithmes de cryptage un peu sérieux :

• Symétriques : DES, RIPLE_DES, RIPLE_DES_3KEY, RC2, RC4, RC4_128, DESX, AES_128, AES_192, AES_256
• Asymétriques : RSA_512, RSA_1024, RSA_2048

La plupart des SGBDR sérieux comme Oralce ou SQL Server utilisent systématiquement un chiffrement (et non cryptage) des mots de passe de type DES à minima !

A +

A +

[CinePhil]

Peut-être que je ne suis pas doué mais j'ai l'impression qu'ils ont corrigé en mettant en oeuvre l'URL rewriting. En tout cas, je ne trouve pas de liens avec un mot de passe.

Pour autant que je sache, Le Figaro a son site développé à partir de Drupal et je crois que c'est Linagora qui a fait la prestation.

[vmolines]

A la date de parution de cette actu, les mots de passes ressortaient toujours. Regardez les commentaires pour les dégâts potentiels. Un simple hashage aurait déjà bien limité les dégâts, un hashage salé les aurait presque réduit à néant.

edit: je dis une bêtise : Explication de la faille

Au final sans rapport avec le sujet puisque je partais de l'hypothèse que les mdp étaient stockés en clair.

Mais il n'y a aucune utilité de stocker le mdp saisi au départ pour vérifier que c'est bien le même qui est resaisi lors de l'authentification. Donc autant ne pas le stocker en clair.

[Waldar]

Au niveau de la CNIL, ils en pensent quoi ?
J'ai cherché rapidement sur le site mais je n'ai pas trouvé d'explication précise sur les mots de passe.

[StringBuilder]

J'ai discuté de ce problème sur G+, et crypté ou pas, le problème serait le même. Le souci, c'est que jamais de la vie le mot de passe ne devrait :
1/ Etre baladé entre le client et le serveur plus d'une fois par session (au moment de l'authentification)
2/ Jamais de la vie dans une querystring

Ici, si le mot de passe était crypté, on pourrait toujours exploiter ces url pour s'authentifier à la place de l'utilisateur sur le site, et ainsi effectuer des opérations à leur place.

[StringBuilder]

Au niveau de la CNIL, ils en pensent quoi ?
J'ai cherché rapidement sur le site mais je n'ai pas trouvé d'explication précise sur les mots de passe.

Pour moi, la CNIL n'a de compétence que d'un point de vue "fonctionnel", c'est à dire "ce qu'on fait de quelle information, notamment comment on la récupère, comment on la restitue et comment on la diffuse". Les aspects techniques ne sont, à mon avis, pas du ressort de la CNIL.

[vmolines]

J'ai rectifié mon post suite à la découverte de l'explication. Ca n'enlève rien à l'inutilité de stocker un mdp en clair.