espace membre, brute force et parades en php
Le
Thierry
Bonjour,
Sur une site php en cours de création, j'ai un espace membre accessible
par WWW-Authenticate: Basic.
J'essaye de sécuriser raisonnablement l'accès à cet espace membre, via
le script php. Le fait d'y accéder ne serait pas catastrophique, mais
l'authentification permet d'accéder à un second niveau de droit pour
administrer le site (modification de pages via une base de données).
L'accès frauduleux à ce second niveau de droit serait nettement plus
ennuyeux.
J'ai donc prévu :
- Un très petit nombre de personnes pourra accéder à ce niveau de droit
pour éditer le site (maxi 3 personnes).
- Rien sur le site ne permet de deviner à priori l'existence de cette
fonctionnalité (seul l'accès membre est indiqué).
- Les login/mdp pour accéder aux droits d'éditions seront plus solides
que les autres (login pas facile à deviner ; mots de passe de 8
caractères avec chiffres et signes).
Après avoir fait quelques recherches (je n'y connais pas grand chose à
la base), je soupçonne deux principaux risques :
1 - L'attaque par brute force ou dictionnaire. Il semble facile à
n'importe qui de trouver sur internet un programme qui fait ça
automatiquement.
-> Pour contrer ce pb, l'implémentation d'un time out semble l'idéal. A
priori, ça nécessite de repérer les demandes d'authentification qui
proviennent de la même source, ce qui semble difficile en php (l'IP,
visiblement, ça ne fonctionne pas, et je ne souhaite pas ennuyer les
utilisateurs avec un cookie obligatoire).
J'ai donc placé un sleep(1) avant la fonction d'authentification (celle
qui envoi le "header('WWW-Authenticate: Basic". Une attente d'une
seconde me parait peut contraignante pour les utilisateurs, et j'imagine
peut-être à tord que ça limite le nombre d'essai à 60 par minute, ce qui
me semble compliquer la tâche au script-kiddie qui veut jouer.
A priori, le script-kiddie trouvera peut-être le moyen d'accéder à
l'espace membre, ce qui ne sera encore une fois pas très grave, mais
l'accès aux fonctions d'éditions seront à priori beaucoup plus difficile
voir quasi-impossible.
A votre avis, est-ce une idée idiote, utile, inutile, quelles sont les
failles de mon raisonnement, etc. (et accessoirement pourquoi ?).
2 - La seconde attaque potentiel, c'est le sniffage de paquets (concept
que je n'est pas très bien compris), pour récupérer login et mots de
passe puisqu'ils sont transmis en clair par la méthode "basic".
-> De ce que j'ai cru comprendre, c'est une méthode nettement plus
complexe à mettre en oeuvre, et il me parait assez improbable qu'un
petit site associatif soit la cible d'une telle attaque. Me trompe-je ?
Merci de vos lumières.
--
Thierry
Sur une site php en cours de création, j'ai un espace membre accessible
par WWW-Authenticate: Basic.
J'essaye de sécuriser raisonnablement l'accès à cet espace membre, via
le script php. Le fait d'y accéder ne serait pas catastrophique, mais
l'authentification permet d'accéder à un second niveau de droit pour
administrer le site (modification de pages via une base de données).
L'accès frauduleux à ce second niveau de droit serait nettement plus
ennuyeux.
J'ai donc prévu :
- Un très petit nombre de personnes pourra accéder à ce niveau de droit
pour éditer le site (maxi 3 personnes).
- Rien sur le site ne permet de deviner à priori l'existence de cette
fonctionnalité (seul l'accès membre est indiqué).
- Les login/mdp pour accéder aux droits d'éditions seront plus solides
que les autres (login pas facile à deviner ; mots de passe de 8
caractères avec chiffres et signes).
Après avoir fait quelques recherches (je n'y connais pas grand chose à
la base), je soupçonne deux principaux risques :
1 - L'attaque par brute force ou dictionnaire. Il semble facile à
n'importe qui de trouver sur internet un programme qui fait ça
automatiquement.
-> Pour contrer ce pb, l'implémentation d'un time out semble l'idéal. A
priori, ça nécessite de repérer les demandes d'authentification qui
proviennent de la même source, ce qui semble difficile en php (l'IP,
visiblement, ça ne fonctionne pas, et je ne souhaite pas ennuyer les
utilisateurs avec un cookie obligatoire).
J'ai donc placé un sleep(1) avant la fonction d'authentification (celle
qui envoi le "header('WWW-Authenticate: Basic". Une attente d'une
seconde me parait peut contraignante pour les utilisateurs, et j'imagine
peut-être à tord que ça limite le nombre d'essai à 60 par minute, ce qui
me semble compliquer la tâche au script-kiddie qui veut jouer.
A priori, le script-kiddie trouvera peut-être le moyen d'accéder à
l'espace membre, ce qui ne sera encore une fois pas très grave, mais
l'accès aux fonctions d'éditions seront à priori beaucoup plus difficile
voir quasi-impossible.
A votre avis, est-ce une idée idiote, utile, inutile, quelles sont les
failles de mon raisonnement, etc. (et accessoirement pourquoi ?).
2 - La seconde attaque potentiel, c'est le sniffage de paquets (concept
que je n'est pas très bien compris), pour récupérer login et mots de
passe puisqu'ils sont transmis en clair par la méthode "basic".
-> De ce que j'ai cru comprendre, c'est une méthode nettement plus
complexe à mettre en oeuvre, et il me parait assez improbable qu'un
petit site associatif soit la cible d'une telle attaque. Me trompe-je ?
Merci de vos lumières.
--
Thierry
Poser une question
ne t'inquette pas, ils trouveront bien
et majuscule, ça peut etre bien aussi (26 possibilité de plus !)
sans comter que le cookie ne risque pas d'etre un probleme pour
l'attaquant puisqu'il est sur sa machine.
Si il n'y as pas grand monde, je ne voit pas le problème : pas plus de 5
essai, ou pas plus d'un toute les 3 secondes. Le mieux, c'est de
désactiver temporairement le login sur lequel il y a eu trop d'essai :
la personne te contacte et tu réactive. Comme ça en plus, si attaque il
y a, tu peux être au courant.
s'échanger nos trouvailles sur le net, il n'était pas publique, donc
personne d'autre que nous ne venait dessus... pour cela, j'ai fait
l'erreur de négliger la sécurité. Résultat : un script-kiddie m'a effacé
la base...
Je pense donc que tu te trompes, justement, le script kiddie attaque les
proies facile. pour ton problème de sniffing, 2 solution : soit tu
utilise HTTPS, soit, tu crypte le mot de passe sur la machine client
avant de l'envoyer (en java script par exemple) mais pour utiliser cette
solution dans certaines condition, dit toi qu'elle est très
contraignante : il vaux mieux que tout tes utilisateurs aient activé
java script, et il vaux aussi mieux vérifier que l'encodage à été fait
coté client (par exemple avec un champ caché dont la valeur est changé
par javascript, résultat, si la valeur est d'origine, le mot de passe
n'a pas été crypté, sinon, il y a de forte chance qu'il l'ait été. une
autre vérification, coté serveur et de contrôlé la signature de la
chaîne de caractère : si tu crypte en md5, par exemple, la chaîne envoyé
ne doit avoir que des caractères hexa et ne peut faire que 32 caractères
de long, donc ctype_xdigit et strlen pourront servir de contrôle) mais
ça reste du gros bricolage, personnellement, je fait ça quand mon client
ne veux pas se payer un certificat SSL...
Est-ce vraiment efficace ?
Exemple : mon mot de passe est "AZERTY"
Une fois crypté, ça donne "fsdgdfgdfgdfgdf", le pirate passe par là et
détecte passe=fsdgdfgdfgdfgdf, il n'a qu'à refaire une requête avec la
même chaine de caractère déjà crypté en md5.
Bon OK, il ne connaitra pas le mot de passe non crypté, et ne poura
donc pas l'utiliser ailleurs (dans l'hypothèse où le mot de passe
protège plusieurs accès) mais il sera quand même rentré dans ta zone.
Vous me comprenez ?
Qu'utilisez vous pour pallier ça ?
Eric
Il me semble que ta question dépasse très largement le contexte décrit
au départ par Thierry
Cela dit, pour éviter qu'un pirate réutilise un mot de passe qu'il a
sniffé, on peut utiliser un système de défi/réponse : le serveur envoie
une information variable qui sert à constituer le mot de passe en
réponse. Pour plus de précision, je te suggère de questionner les
lecteurs du forum fr.comp.securite.
eça
--
P'tit Marcel
La premiere chose est de se premunir contre les injections SQL.
La seconde est d'avoir un mot de passe fort avec combinaison de lettres
(maj/min), chiffres, et un caractere @#~.
Le timeout peut etre un complement mais la méthode de petit marcel (un
compteur d'echec) est suffisante.
[SNIF]
Le facteur n'est pas le site mais d'où se connecte la personne.
Impossible si la personne qui se loggue est en direct sur Internet, possible
si elle est sur un Intranet/réseau familial, cybercafé mal sécurisé.
Oui. Disons de ce que j'ai compris notamment en lisant les docs de ce
forum qu'il s'agit de sécurité par obscurité, et qu'il ne faut pas
compter dessus. Disons qu'a contrario, je pense que ce n'est pas plus
mal que de mettre en évidence du genre « attention, il y a un secret
->ici
[...]
Yep, c'est exactement l'idée que je cherchais, et que je vais mettre en
place pour les comptes qui donnent accès aux fonctions d'édition. Merci.
Etait-ce vraiment une attaque par sniffing, ou tout autre chose genre
utilisation d'une faille ou injection sql ?
[...]
Je n'ai pas moyen d'utiliser https et je souhaite éviter d'imposer le
javascript. Je pense aussi que l'objection d'Eric sur l'efficacité du
cryptage est valable (voler le mot de passe sous sa forme crypté est
suffisant pour acceder au compte).
Du coup, et comme le rappelle P'tit Marcel, on s'éloigne de la charte de
ce forum, et j'essayerais donc de demander des précision sur
fr.comp.securite.
Bonne journée/soirée/ce que vous voudrez,
--
Thierry