Discussion :

[julien.63]

Salut,
Je suis en train de faire un site où les gens doivent s'inscrire. Pour l'instant les mots de passe sont enregistrés en clair dans la base de données. Donc toute personne ayant accès à la base peut les voir.

De quelle façon peut on crypter les mots de passes?

j'ai pensé à la fonction base64_encode() qui renvoi une chaine a priori sans sens. Mais bon je ne suis pas sur que cela soit très sécurisé car il est très facile de les decoder...

merci

Julien

[Yogui]

Salut

La solution simple : md5() sur ton mot de passe.
Quand un membe souhaite se loguer, tu compares son pseudo et le md5 du mot de passe envoyé à ce que tu as dans la base.
Autre solution : stocker le md5 du md5... Ainsi, tu peux envoyer crypter le mot de passe en md5 via Javascript avant qu'il transite par le réseau, ce qui ajoute un niveau supplémentaire de sécurité.


Ce sujet a été amplement traité je ne sais plus où sur le forum. Il me semble que la solution que je viens de te donner a été présentée (avec davantage de détails) par vg33. [Edit : c'est ici => http://www.developpez.net/forums/showthread.php?t=98673]

Certains programmeurs préfèrent crypt() à md5(). À chacun de voir sa préférence.

[Jarodd]

Bonjour,

J'allais répondre la même chose qu'Yogui avant de voir sa réponse

Pour ma part, j'utilise la fonction sha1(), elle stocke plus de caractères que md5(). Je ne sais pas si cela a une influence sur la sécurité, peut-ête est-elle accrus car plus difficile à décrypter ?

[Yogui]

Bof, tout dépend des autres mécanismes de sécurité : par exemple, si tu empêches à quelqu'un de faire plus de 3 tentatives infructueuses en un temps donné, ça réduit largement plus les risques qu'en utilisant sha1(). Plus cette période de ban est longue, plus tu empêches les attaques (mais plus tu embêtes un membre qui a sincèrement oublié son mdp).
Autre chose : les attaques par dictionnaire ne sont valables que si on laisse à l'attaquant le temps de tester son dico. S'il est ralenti avec ma suggestion précédente, ça nous laisse un répit. Si, en plus, un mécanisme de changement du mot de passe est mis en place (mettons toutes les 2 semaines : il faut un temps court pour que cela soit utile), alors c'est le top et il y aura vraiment une très faible proba pour que l'attaquant ait un résultat qui lui serve.

[ePoX]

Je rajouterais juste que si aujourd'hui sha est préféré à md5 c'est parceque jusqu'à l'heure actuel on n'à pas encore réussi à le faire défaillir.

En revanche md5, à subit plusieurs attaques, notamment sur les *probabilités* de créér des chiffrement identique avec deux contenus différents, ou collisions.

M'enfin bon, ce n'est pas comme si tu faisais le site d'une banque hein
Donc ces détails sont mineures pour le moment.

[julien.63]

Effectivement, je ne fais pas le site d'une banque et ce que vous m'indiquez me semble parfait.
Merci pour vos conseils.
@+
Julien

[ShinJava]

Bof, tout dépend des autres mécanismes de sécurité : par exemple, si tu empêches à quelqu'un de faire plus de 3 tentatives infructueuses en un temps donné, ça réduit largement plus les risques qu'en utilisant sha1().

Désolé pour cette intrusion
Tu t'y prend comment pour l'histoire du nombre des tentatives ?
Faut-il faire cela selon une variable (session) qui s'incremente à chaque fois que la tentative à échouer ? (et la au bout de 3, on refuse la personne de valider le formulaire)
Ou bien, stocké l'IP de l'attaquant dans une BDD + une colonne tentative (qu'on incremente à chaque tentative raté). Dès qu'on arrive à 3, on met l'IP dans une table BANNI qui sera verifier à chaque fois que quelqu'un rempli le formulaire (c'est un peu lourd non ?).
Merci pour vos futurs éclaircissement.

++
ShinJava

[Yogui]

Tout dépend de la durée maxi que tu autorises entre 2 tentatives. Si ça commence à durer, il vaut mieux passer par la BDD (plus sûr mais légèrement plus coûteux à mettre en place), sans quoi ta variable de session risque d'expirer...

Je recommande la version BDD mais attention à réinitialiser le compteur au bon moment !

[ShinJava]

Tout dépend de la durée maxi que tu autorises entre 2 tentatives. Si ça commence à durer, il vaut mieux passer par la BDD (plus sûr mais légèrement plus coûteux à mettre en place), sans quoi ta variable de session risque d'expirer...

Je recommande la version BDD mais attention à réinitialiser le compteur au bon moment !

Merci pour cette précision Je vais me tourner vers la solution BDD dans ce cas la.

Bonne journée.
++
ShinJava