J’aurais une (deux en fait) petites questions, auquel vous pourriez peut être m’aider à répondre.
1- Le formulaire de login et le bruteforce.
Un audit de sécurité d’un de mes sites SPIP me dit qu’il faut que je mette une protection contre le brute force (robot qui soumet en continu un dictionnaire de login/password) et l’argument “on a mis des password long et imbitable plein de caractères spéciaux” ne satisfait pas les plus tatillons.
Une idée pour faire ça ?
Probablement surcharge de prive/formulaires/login.php
J’envisageais un trucs pour logguer dans une table les tentative de connexion/IP et bloquer la soumissions après N tentatives. Mais j’ignore si c’est assez efficace (je doute qu’un pirates est une IP fixe).
Bref, toute piste est la bienvenue (et non, je ne peux pas utiliser l’annuaire LDAP). Aucun plugin ne fait déjà ça ?
2- Balise non-cachée
Pour ma culture personnelle : est-il possible de créer des balises SPIP qui ne soit pas prise en compte dans le cache ?
Cela semble possible avec les" balises dynamiques", mais je dois avouer les trouver un peu nébuleuse malgré la doc (et ça semble très lié à CVT). Et en plus, elles ne sont apparemment pas “filtrable”.
Par exemple, j’ai une balise (statique si j’ai tout compris) :
function balise_QUEL_ECRAN_dist($p){
$p->code = “quel_ecran()”;
return $p;
}
Cette balise que j’ai crée lance une fonction PHP, renvoyant un texte donnant des infos sur le visiteur (navigateur, IP, OS, sur mobile, …).
L’ennui, c’est que sur le site, la page ayant un cache standard, seule les informations du visiteurs ayant “générer” le cache sont affichées. Ces sont donc ses informations qui sont servies à tout le monde, chose que je ne veux pas.
Une simple inclusion d’un squelette avec #CACHE{0} et la balise résous certes le problème, mais c’est un peu lourd… Il n’y a pas un moyen de désactiver le cache pour la balise directement (genre un $p->interdire_cache ?).
J'aurais une (deux en fait) petites questions, auquel vous pourriez peut être m'aider à répondre.
1- Le formulaire de login et le bruteforce.
Un audit de sécurité d'un de mes sites SPIP me dit qu'il faut que je mette une protection contre le brute force (robot qui soumet en continu un dictionnaire de login/password) et l'argument "on a mis des password long et imbitable plein de caractères spéciaux" ne satisfait pas les plus tatillons.
Une idée pour faire ça ?
Probablement surcharge de prive/formulaires/login.php
J'envisageais un trucs pour logguer dans une table les tentative de connexion/IP et bloquer la soumissions après N tentatives. Mais j'ignore si c'est assez efficace (je doute qu'un pirates est une IP fixe).
Bref, toute piste est la bienvenue (et non, je ne peux pas utiliser l'annuaire LDAP). Aucun plugin ne fait déjà ça ?
J’aurais une (deux en fait) petites questions, auquel vous pourriez peut être m’aider à répondre.
1- Le formulaire de login et le bruteforce.
Un audit de sécurité d’un de mes sites SPIP me dit qu’il faut que je mette une protection contre le brute force (robot qui soumet en continu un dictionnaire de login/password) et l’argument « on a mis des password long et imbitable plein de caractères spéciaux » ne satisfait pas les plus tatillons.
Une idée pour faire ça ?
Probablement surcharge de prive/formulaires/login.php
J’envisageais un trucs pour logguer dans une table les tentative de connexion/IP et bloquer la soumissions après N tentatives. Mais j’ignore si c’est assez efficace (je doute qu’un pirates est une IP fixe).
Bref, toute piste est la bienvenue (et non, je ne peux pas utiliser l’annuaire LDAP). Aucun plugin ne fait déjà ça ?
CAS est un mécanisme d’authentification SSO. cf. http://www.jasig.org/cas
Le plugin que tu cites ne fais que permettre d’utiliser un serveur CAS (galère à mettre en place au passage) pour connecter SPIP.
Rien à voir avec une stratégie dans SPIP pour bloquer les attaques de type bruteforce.
Le seul moyen via SPIP est effectivement de vérifier si une IP ne fait pas plus de N erreurs.
Des scripts PHP existent.
Celui-ci en particulier : http://richard.gluga.com/2010/05/simple-php-anti-brute-force-login.html
Il définit une classe statique facile à appeler dans le formulaire de login.
Je pense plutôt que la meilleure stratégie serait simplement de ne permettre qu’un nombre limité d’essai de connexion par login et par 24h.
Ainsi les attaquants par force brute qui essayent un login valide ne verront que leur N premières tentatives prises en compte et tout le reste sera rejeté comme erroné sans permettre a l’attaquant de savoir que le rejet est lié au nombre d’essais.
Cela limiterait beaucoup les possibilité de succès d’une attaque par force brute sans gêner vraiment les utilisateurs (avec un N > 10 ou 20 ?), et sans reposer sur un en-tête aisément falsifiable.
Le seul moyen via SPIP est effectivement de vérifier si une IP ne fait pas plus de N erreurs.
Je pense plutôt que la meilleure stratégie serait simplement de ne permettre qu’un nombre limité d’essai de connexion par login et par 24h.
Ainsi les attaquants par force brute qui essayent un login valide ne verront que leur N premières tentatives prises en compte et tout le reste sera rejeté comme erroné sans permettre a l’attaquant de savoir que le rejet est lié au nombre d’essais.
Cela limiterait beaucoup les possibilité de succès d’une attaque par force brute sans gêner vraiment les utilisateurs (avec un N > 10 ou 20 ?), et sans reposer sur un en-tête aisément falsifiable.
Ca me semble effectivement une bonne stratégie.
Sur le site d’OWASP (Open Web Application Security Project) https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
il est clairement indiqué que bloquer sur une IP n’est pas satisfaisant.
Le formulaire de login, au bout de 3 essais pourrait mettre en avant l’option de réinitialisation du mot de passe
(je ne sais pas pourquoi si peu de monde que j’ai vu débuter savent utiliser ce lien)
Et effectivement, avec l’approche de Cédric, la seule option pour se connecter serait soit de réinitialiser son mot de passe, soit d’attendre 24h. Il faudrait quand même l’expliquer dans le formulaire de login.
Mais ça me semble d’avantage le rôle d’un plugin que d’une fonctionnalité du core, ce type de customisation (sachant qu’il y en a qui vont vouloir faire comme d’autres grands sites et rajouter du Captcha au bout d’un certain nombre d’échecs
Et effectivement, avec l'approche de Cédric, la seule option pour se
connecter serait soit de réinitialiser son mot de passe, soit
d'attendre 24h. Il faudrait quand même l'expliquer dans le formulaire
de login.
Le problème de cette approche est qu'elle permet le déni de service: si
je veux te faire chier, je fais des échecs avec ton login et tu es
bloqué.
Une autre stratégie possible, souvent utilisée sur les OS, est
d'induire un léger délai avant d'accepter ou refuser
l'authentification. Avec un délai bien choisi, ça permet de rendre
impraticable une attaque par force brute tout en restant imperceptible
pour une connexion normale. Pour raffiner le truc, ce délai peut être
proportionnel au nombre d'échecs récents.
Merci pour vos réponses, ça va me permettre de creuser un peu le truc (et qui sait, d’en faire un plugin, même si plus de sécurité c’est toujours bien, non).
J’aime bien l’idée de Cédric, évidente une fois qu’on la voit posée. A voir si j’arrive à la réaliser et même à ajouter la solution de davux/Gilles en prime.
