8791 sujets

Développement web côté serveur, CMS

Pages :
(reprise du message précédent)

Christele a écrit :

Et aprés quand je vois avec horreur le nombre de site ou le mot de passe
de phpmyadmin est damandé tout bétement dans mon_site.com/phpmyadmin/
alors OUI ce mot de passe devrais étre haché mais justement c'est pas possible ! Smiley fache


Justement, dans ce cas là, le mot de passe n'est pas stocké dans un fichier de conf, puisque c'est l'utilisateur qui le fournit quand il a besoin de se connecter.
Dans MySQL, le mot de passe est justement hashé (suivant un algorithme bien à eux d'ailleurs).

Et pour revenir au sujet, aujourd'hui, ce qui fournit la meilleure sécurité, c'est bien le "salted SHA-1" (ou SHA-256 mais vu que c'est quasi le même algo, il sera attaqué de la même manière que SHA-1). Il y a des bouts de code qui trainent sur google Smiley smile
Tony Monast a écrit :
En Coldfusion par exemple, je ne fait qu'indiquer le nom de la datasource dans mes requêtes. En aucun temps les identifiants de la base de données sont dans les fichiers du site. Ils sont gérés via une interface d'administration, elle-même protégée par mot de passe chiffré. Il y a sans doute une possibilité de le faire aussi dans PHP si on souhaite réellement ne pas afficher en clair le mot de passe de la base de données dans un include.


Cet aspect de Coldfusion (la grosse interface d'admin accessible en mode web sur le serveur qui permet de tout configurer) m'avait interloqué la première fois que j'ai fait du CF, moi qui vient d'un background PHP.
Je ne sais pas comment c'est faisable en PHP, la logique n'est pas la même, CF est vraiment un gros service qui tourne en permanence avec ses layers d'abstraction, son cache interne, etc, etc. C'est un des gros plus que j'ai trouvé à ce langage.

Bref, je m'égare, mais tout cela pour dire que rien que pour masquer aux yeux du webmaster, de l'hébergeur ou de n'importe qui le mot de passe en clair des utilisateurs, il faut hasher les mots de passe.
Et les salter pour éviter que la compromission de cette base puisse atteindre d'autres bases grâce a des rainbow tables.

Et ce n'est pas parce que certaines gros sites (Monster par exemple) ne prennent pas ce genre de précautions qu'on ne doit pas le faire sur nos sites à plus petite envergure.
Très intéressant votre topic. Smiley smile

Quelqu'un aurait un lien vers un rapide tuto sur le sha + salt ?
(j'adore le chat bien salé Smiley biggol )
Le problème de sha1 et md5 , c'est leur rapidité (ils on été conçus pour cela) qui rend la gééation de rainbow ...rapide.
D 'autres algos tels que bcrypt (qui repose sur blowfish) sont beaucoup plus lents, ce qui ralentit d'autant les copains hackers.
Cela dit, l'ajout d'un salt suffisamment long et bien placé (pas obligé de le mettre au début) suffit pour la beaucoup d'applis.

Aucun algo ne va rendre votre site plus sûr à lui tout seul. Si votre login/mdp c'est 2 fois le prénom de la rédactrice trouvé sur le site (c'est du vécu), aucun hash ne pourra rien pour vous...

Certains cms ont de plus la mauvaise idée d'informer sur la validité du login (spip, wordpress), ce qui facilite d'autant le travail de hack.

La sûreté d'un site doit s'appréhender de manière globale.
Pages :