espace membre, brute force et parades en php

[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.

[Thief13]

Post by Thierry
- Rien sur le site ne permet de deviner à priori l'existence de cette
fonctionnalité (seul l'accès membre est indiqué).

ne t'inquette pas, ils trouveront bien

Post by Thierry
- 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).

et majuscule, ça peut etre bien aussi (26 possibilité de plus !)

Post by Thierry
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).

sans comter que le cookie ne risque pas d'etre un probleme pour
l'attaquant puisqu'il est sur sa machine.

Post by Thierry
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.

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.

Post by Thierry
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 ?

Personnellement, j'avais un forum sur lequel on était que 3 copains à
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...

Post by Thierry
Merci de vos lumières.

J'espère que j'aurais pu t'éclairer avec ma petite lampe torche...

[Eric]

[...] soit, tu crypte le mot de passe sur la machine client
avant de l'envoyer (en java script par exemple) [...]

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

[P'tit Marcel]

Post by Eric

[...] soit, tu crypte le mot de passe sur la machine client
avant de l'envoyer (en java script par exemple) [...]

Est-ce vraiment efficace ?
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.
Qu'utilisez vous pour pallier ça ?

Il me semble que ta question dépasse très largement le contexte décrit
au départ par Thierry -@invalid

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

[Thief13]

Post by Eric
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

Pour faire une requête, il faut soit qu'il ai le mot de passe de la base
de donnée (et là, bon, y'a plus à s'inquiéter de la sécurité du script,
c'est trop tard ^^) soit qu'il fasse une injection (à priori, il suffit
de filtrer toutes les variables envoyé par l'utilisateur, pour ma part,
je fait en sorte que l'utilisateur ne m'envoi que des valeur numériques,
après, je fait un intval() dessus. et si, par hasard, j'ai besoin
d'autre chose, je fait toujours un MD5 dessus, donc, ça va être dur de
faire une injection comme ça. et quand bien même, j'utilise les session
pour vérifier que la page qui est sensé faire la requête à bien été
appelé par la bonne page, et non par une page locale...
Je me fourvoie peut être, mais je pense qu'il aura du mal à faire la
requête. Sa seule solution et de retrouver le mot de passe à partir du
hash avec MDcrack... alors, c'est sur qu'avec une mot de passe comme
AZERTY il n'aura pas de mal, mais avec des mot de passe de plus de 8
caractère mélangeant chiffre et caractères spéciaux, il risque d'en
avoir pour un moment, sauf si il a de bonnes rainbow table, mais là,
c'est un bon qui vous en veux vraiment ! Il finira bien par passer...

Il vaux quand meme mieux qu'il sniff le hash plutot que le pass en
clair, apres... le mieux, c'est toujour s'utiliser SSL, mais bon, meme
la, j'ai un tuto qui explique comment sniffer et décrypter en temp réel
des transactions en SSL.

[Thierry]

Post by Thief13

Post by Thierry
- Rien sur le site ne permet de deviner à priori l'existence de cette
fonctionnalité (seul l'accès membre est indiqué).

ne t'inquette pas, ils trouveront bien

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<- ».

Post by Thief13

Post by Thierry
- 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).

et majuscule, ça peut etre bien aussi (26 possibilité de plus !)

Post by Thierry
1 - L'attaque par brute force ou dictionnaire. Il semble facile à
n'importe qui de trouver sur internet un programme qui fait ça
automatiquement.

[...]

Post by Thief13
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
la personne te contacte et tu réactive. Comme ça en plus, si attaque il
y a, tu peux être au courant.

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.

Post by Thief13

Post by Thierry
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 ?

Personnellement, j'avais un forum sur lequel on était que 3 copains à
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...

Etait-ce vraiment une attaque par sniffing, ou tout autre chose genre
utilisation d'une faille ou injection sql ?

Post by Thief13
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)

[...]

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,

[Thief13]

Post by Thierry

Post by Thief13
Personnellement, j'avais un forum sur lequel on était que 3 copains à
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...

Etait-ce vraiment une attaque par sniffing, ou tout autre chose genre
utilisation d'une faille ou injection sql ?

injection, mais ça ne change rien, ce n'est pas parce que un site est
peut fréquenté qu'il faut négliger la sécurité.

Post by Thierry
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).

Je suis tout a fait d'accord avec toi pour le coté client (a mort les
sites qui dépendent de javascript pour leur navigation !), mais pour le
coté admin, je ne voix pas le probleme : il y a tres peux
d'utilisateurs, tu peut donc imposer certaines contraintes sans trop de
risque.

de plus, si tu vérifie que la page qui fait la requette SQL à bien été
appellé depuis la bonne page, grasse a une session par exemple, je ne
voix pas trop le probleme : la page de connection défini par exemple

$_SESSION['source'] = 'login';

et sur le page de connexion tu fait quelque chose dans le genre

if ($_SESSION['source'] != 'login') {
exit('Vous n'avez pas appelé cette page du bon endroit');
} else {
unset($_SESSION['source']);
}

a partire de la, meme si il envoi le bon mot de passe depuis une page en
local, ça ne marchera pas. il est obligé de passer par ta page, dans
laquelle il est obligé de taper le mot de passe en clair...

By

[Eric]

On 20 fév, 18:39, Thief13 <***@nospam.org> wrote:
[...]

Post by Thief13
a partire de la, meme si il envoi le bon mot de passe depuis une page en
local, ça ne marchera pas. il est obligé de passer par ta page, dans
laquelle il est obligé de taper le mot de passe en clair...
By

On parie ?

J'ai déjà vu tout plein de programmes qui sont écrits pour faire telle
ou telle opération (typiquement envoyer un sms) sans passer par le
site.
1. Il va chercher la page formulaire en envoyant les entêtes d'un
navigateur existant
2. Il récupère l'ID de session dans les entêtes
3. Il va chercher la seconde page en rendant cet identifiant de
session

Tapez SMS dans des sites comme vbfrance.com...

OK, le gars t'en veut *vraiment* mais si on veut vivre dans la parano,
oui, c'est une méthode.
Donc placer un compteur d'échec non pas sur une session mais sur une
IP (bon d'accord, il y a un biais car avec les routeurs, plusieurs
personnes peuvent se connecter depuis la même IP, mais ce biais me
semble être tolérable ici)

[Thief13]

Post by Eric
OK, le gars t'en veut *vraiment* mais si on veut vivre dans la parano,
oui, c'est une méthode.

Mais de toute façon tu peut mettre la plus grosse sécurité que tu veux,
il y aurra TOUJOURS un moyen de la contourner... Tout ce que l'on peut
faire, c'est de compliquer au maximum la vie aux attaquants potentiels,
et plus on lui complique la vie, moi il y aurras d'attaquants
potentiels, c'est tout ce que peut apporter la sécurité. Ceci dit,
j'aurrais du dire, il aurra de mal à envoyer les information sans passer
par ta page, plutot que il est obligé de passer par ta page, désolé...

De plus, on débat quand même sur une solution gros bricolage que j'ai
proposé en dernier recourt pour éviter que les passwords transits en
clair sans SSL, mais il vaux quand meme vraiment mieux passer en SSL
(mais si là encore, il y a moyent de snifer et décrypter en temps réel).

Post by Eric
Donc placer un compteur d'échec non pas sur une session mais sur une
IP (bon d'accord, il y a un biais car avec les routeurs, plusieurs
personnes peuvent se connecter depuis la même IP, mais ce biais me
semble être tolérable ici)

Pour ma part, je suis convaincu de la nécessité du compteur d'échec,
ansi que celle d'un timer entre chaque essai

[Thierry]

Post by Thierry
1 - L'attaque par brute force ou dictionnaire. Il semble facile à
n'importe qui de trouver sur internet un programme qui fait ça
automatiquement.

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]

Post by Thierry
-> 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 ?

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é.

[Thief13]

Post by Thierry
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

Meme si l'attaquant est sur la plage d'IP que la victime ?

Post by Thierry
possible
si elle est sur un Intranet/réseau familial, cybercafé mal sécurisé.

Comment tu fait pour sécuriser un réseau contre l'interception des
données qui circulent en clair dessus ?

[Thierry]

Post by Thief13

Post by Thierry
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

Meme si l'attaquant est sur la plage d'IP que la victime ?

oui

Post by Thief13

Post by Thierry
possible
si elle est sur un Intranet/réseau familial, cybercafé mal sécurisé.

Comment tu fait pour sécuriser un réseau contre l'interception des
données qui circulent en clair dessus ?

https

Xpost + fu2 fcs ou c'est plus en theme (et de plus pas modéré :-)