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 ?
- 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
- 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 !)
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.
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.
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...
Merci de vos lumières. J'espère que j'aurais pu t'éclairer avec ma petite lampe torche...
- 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
- 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 !)
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.
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.
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...
Merci de vos lumières.
J'espère que j'aurais pu t'éclairer avec ma petite lampe torche...
- 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
- 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 !)
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.
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.
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...
Merci de vos lumières. J'espère que j'aurais pu t'éclairer avec ma petite lampe torche...
Eric
On 18 fév, 13:46, Thief13 wrote:
[...] 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
On 18 fév, 13:46, Thief13 <Thie...@nospam.org> wrote:
[...] 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 ?
[...] 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
On 18 fév, 13:46, Thief13 wrote:
[...] 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
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
On 18 fév, 13:46, Thief13 <Thie...@nospam.org> wrote:
[...] 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.
[...] 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
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
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]
-> 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é.
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]
-> 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é.
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]
-> 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é.
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<- ».
- 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 !)
1 - L'attaque par brute force ou dictionnaire. Il semble facile à n'importe qui de trouver sur internet un programme qui fait ça automatiquement.
[...]
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.
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.
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 ?
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, -- 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<- ».
- 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 !)
1 - L'attaque par brute force ou dictionnaire. Il semble facile à
n'importe qui de trouver sur internet un programme qui fait ça
automatiquement.
[...]
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.
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.
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 ?
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,
--
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<- ».
- 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 !)
1 - L'attaque par brute force ou dictionnaire. Il semble facile à n'importe qui de trouver sur internet un programme qui fait ça automatiquement.
[...]
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.
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.
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 ?
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, -- Thierry
Thief13
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.
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.
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.
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é.
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
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é.
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...
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é.
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
Thief13
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
Eric
On 20 fév, 18:39, Thief13 wrote: [...]
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)
On 20 fév, 18:39, Thief13 <Thie...@nospam.org> wrote:
[...]
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)
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
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).
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
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).
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
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).
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
