Commentaires et Suggestions

Bonjour,

Je tenais à vous suggérer d’offrir la possibilité de se connecter au travers du protocole HTTPS. Actuellement, nos identifiants circulent en clair au travers du protocole HTTP. Je pense que cet écart peut être simplement corrigé via (StartSSL ou autre FREE PKI).

Merci du boulot réalisé.

Oui, je viens de m’inscrire et j’allais créer un nouveau sujet sur le forum pour exactement la même chose...
Quand même bizarre qu’un site de sécurité n’aient pas le truc le plus basic de sécurité web...

Salut SécuIP,

Tu voudrais protéger quoi avec le chiffrement des données ? Tu as peur qu’on flag des épreuves à ta place ?
Tu as peur pour ton mot de passe ? Vu que ce n’est pas chiffré, utilise un pass qui ne crains rien. C’est tout :)

Bonne root,

TiWim

Tiens TiWim, faudrait que je chope le tiens de pass, ça me permettrait d’aller regarder quelques solutions pour flagger plus vite et faire croire que chuis un top Hacker !

D’autres me répondraient... T’es juste une tapz ^^

Ce sujet revient régulièrement. :)

On peut comprendre l’envie de certains à vouloir tout chiffrer.
Mais n’oubliez pas que sur Root-Me, le mot de passe de votre compte ne circule jamais en clair (sauf si vous désactivez javascript pour root-me.org). Vérifiez par vous-même ;)

Et puis vue la relative forte fréquentation du site, l’impact du chiffrement ne serait pas forcément négligeable sur notre infra.
Après, la discussion reste ouverte.

Yo,

Je vais reprendre ce que j’ai dit sur le channel du staff. Je suis plutôt du côté des pro-chiffrement.
Voilà pourquoi.
Effectivement, les credz sont chiffrés client-side via JS. Mais ce n’est plus le cas si on le désactive (coucou NoJS) parce que le JS c’est caca.
De plus, dans un environnement hostile, on peut se faire chopper le cookie spip et donc se faire voler son compte. Certes, c’est "pas grave", mais un compte c’est privé, non ? :)
Pour la question de l’infra, j’suis pas certain que ce soit vraiment dérangeant niveau ressource.

Le seul problème, c’est de payer un certificat histoire de ne pas y foutre un certificat selfsigned qui va faire gueuler les browser. Mais là, j’en appelle a SecuIP et aux autres : http://www.root-me.org/spip.php?page=don
:D

Bisou.

au pire c’est gratuit un certif ssl pour www seul. http://startssl.com/
Mais franchement, chiffrer avec du js quoi. Pour un site qui parle de sécu c’est culotté.

Alors  😄

notfound fait un abus de langage, vos mot de passe sont bien hashé avec l’algorithme sha256 codé en javascript au moment de l’authentification. Ca permet notamment de vous "protéger" (un hash ca se crack) contre une interception de la communication à ce moment.

Pour ce qui est de la mise en place une couche de chiffrement SSL :
– vu les derniers problèmes d’implémentations dans le domaine, mieux vaut sans qu’avec
– ca coute cher en performance, Arthur : non c’est pas gratuit, a charge égale la puissance de serveur nécessaire est pas la même...

Ce sera sûrement dans quelques temps, quand OpenSSL aura été bien (re)lu ; par exemple quand on migrera sur nginx pour le frontal web.
Bon entraînement !

Je propose de remplacer le serveur ssh par un telnet, ca sera moins groumant en ressources. -> http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose

Plus sérieusement, y’a une chose qui me gène dans ton raisonnement :
On a trouvé des failles dans un plugin (heartbeat), dans SSL 3 (vieux de 20 ans) et quelques vieilleries comme ça, et du coup, tu dis "il vaut mieux sans qu’avec". Je suis presque sûr que non.
C’est comme dire "bha dans 20 ans on pourra craquer les clés pgp, du coup ca sert à rien".
Le raisonnement du tout ou rien ne fonctionne pas en crypto, tu le sais très bien ; il s’agit uniquement d’une course contre la montre. Et rester à jour.
Enfin, comme l’a dit notfound, le chiffrement sans certification, ca ne vaut pas grand chose

note : si les perf vous posent problème, il faudra penser à changer pour autre chose qu’un serveur apache.

Je suis presque sûr que non.

Et je suis sûr que quelqu’un aurait profité de heartbleed pour s’amuser 😉

Si vous arrivez à nous convaincre que voler le cookie de session d’un utilisateur permet de faire des choses folles on en rediscutera mais imho j’en doute :p

Pour les perfs c’est aussi une question de choix, avec notre archi/puissance actuelle, on préfère monter des environnements de challs sympas et variés (genre le nouveau http://www.root-me.org/fr/Challenges/Web-Serveur/Server-side-Template-Injection :) ) plutôt que monter une couche SSL ne protégeant, à notre avis, pas grand chose d’intéressant.

un jour, plus tard...

Au lieu d’avoir une authentification sur du TLS qui n’apporte pas grand chose pour ce site (sniffer un résolution de challenge ? 😛) , peut-être dédier cette puissance de calcul pour des challenges sur les failles SSL/TLS (BEAST, FREAK, HeartBleed, Poodle). :)
Bon après, pas évident de mettre en place de telles plateformes pour ces failles...

On va bien y venir avec HTTP2 d’ici quelque mois, pas vraiment le choix a priori, et puis ça risque de valoir le coup là 😛