On Fri, 2015-01-16 at 01:48 +0100, Emmanuel Thierry wrote: > Le 15 janv. 2015 à 14:11, Florent Daigniere a écrit : > > > On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote: > >> Bonjour, > >> > >> L'ANSSI vous parle > >> > >> http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html > >> --------------------------- > > > > La question c'est de savoir si ça vaut la peine de les écouter :) > > Certaines des recommandations tombent sous le sens.. d'autre sont > > complètement farfelues > > Au contraire ça me parait très équilibré, avec une approche aussi bien sur > l'hébergement que sur le code en lui même. > Le seul problème que je vois est qu'il ne sera probablement jamais lu par les > gens qui en ont vraiment besoin... >
ça frustre les spécialistes et ça n'aide pas les gens qui n'y connaissent rien. Les recommendations devraient être plus simple: R19 -> "Les identifiants de session doivent être imprévisibles" "aléatoires" il faut des notions de statistiques pour comprendre "entropie" il faut des notions de théorie de l'information R20 -> TLS de partout > > > > Exemples : > > > > R19 > > Les identifiants de session doivent être aléatoires et d’une entropie > > d’au moins 128 bits. > > > > -> 128bits pour une attaque en ligne... c'est beaucoup et complètement > > arbitraire > > Il faut bien placer une limite, qui par ailleurs soit durable dans le temps. > En même temps 128bits d'entropie ce n'est pas vraiment compliqué à générer. > Là n'est pas la question; quand on est aussi précis que ça dans une recommendation, qu'il y ait une bonne raison derrière. Là il n'y en a pas et le vocabulaire utilisé est un vocabulaire de spécialiste. Le bon contrôle contre les identifiants de session trop courts c'est de limiter la durée de vie de celle ci. > > > > > R20 > > Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès > > lors que l’on associe une session à des privilèges particuliers. > > > > -> ce n'est pas réducteur du tout comme approche. C'est bien connu, > > l'authentification ça ne sert que dans un sens ;) > > L'idée dans ce cas est surtout de protéger les credentials de l'utilisateur > et la confidentialité des informations. Et c'est bien ce que je reproche a cette recommendation. TLS ça sert avant tout a authentifier le site auquel on est connecte. TLS ça se déploie sur tout le site, pas uniquement post-authentification (pour la raison mentionnée au dessus) > Je crois que c'est clair dans le texte : > "En chiffrant les communications au moyen de TLS, on empêche un attaquant qui > « écoute » le réseau d’apprendre les identifiants de sessions. Certains sites > ont recours à TLS uniquement pour la page d’authentification. Cela protège > certes le mot de passe mais pas l’identifiant de session." > > Par ailleurs ils parlent des certificats client en R4, mais pour > l'administration seulement, parce que ça parait compliqué de faire installer > par chaque utilisateur un certificat. > > Cordialement > Emmanuel Thierry
signature.asc
Description: This is a digitally signed message part
