je restreints l'accès à un site avec htaccess de façon à ce que les
utilisateurs s'identifient personnellement. Comment annuler l'identification
de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour
(afin que la fenêtre d'identification réapparaisse) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Masson
Thierry a écrit :
Bonsoir,
je restreints l'accès à un site avec htaccess de façon à ce que les utilisateurs s'identifient personnellement. Comment annuler l'identification de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour (afin que la fenêtre d'identification réapparaisse) ?
Bonjour,
Pour une utilisation de ce genre, ça ne me semble pas bien approprié. Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Thierry a écrit :
Bonsoir,
je restreints l'accès à un site avec htaccess de façon à ce que les
utilisateurs s'identifient personnellement. Comment annuler l'identification
de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour
(afin que la fenêtre d'identification réapparaisse) ?
Bonjour,
Pour une utilisation de ce genre, ça ne me semble pas bien approprié.
Néanmoins, vous pouvez renvoyer un en-tête :
header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base,
largement utilisée, fait circuler les identifiants en clair.
je restreints l'accès à un site avec htaccess de façon à ce que les utilisateurs s'identifient personnellement. Comment annuler l'identification de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour (afin que la fenêtre d'identification réapparaisse) ?
Bonjour,
Pour une utilisation de ce genre, ça ne me semble pas bien approprié. Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Pierre Goiffon
Thierry wrote:
je restreints l'accès à un site avec htaccess de façon à ce que les utilisateurs s'identifient personnellement. Comment annuler l'identification de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour (afin que la fenêtre d'identification réapparaisse) ?
Pour des besoins de développement, à noter la fonction très pratique de la web developper toolbar (extension Firefox) permettant de réinitialiser les jetons REALM et donc de faire sauter l'authentification.
Thierry wrote:
je restreints l'accès à un site avec htaccess de façon à ce que les
utilisateurs s'identifient personnellement. Comment annuler l'identification
de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour
(afin que la fenêtre d'identification réapparaisse) ?
Pour des besoins de développement, à noter la fonction très pratique de
la web developper toolbar (extension Firefox) permettant de
réinitialiser les jetons REALM et donc de faire sauter l'authentification.
je restreints l'accès à un site avec htaccess de façon à ce que les utilisateurs s'identifient personnellement. Comment annuler l'identification de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour (afin que la fenêtre d'identification réapparaisse) ?
Pour des besoins de développement, à noter la fonction très pratique de la web developper toolbar (extension Firefox) permettant de réinitialiser les jetons REALM et donc de faire sauter l'authentification.
Lea Gris
Bonjour,
Olivier Masson a écrit :
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Oui olivier, avec une nuance :
L'alternative à l'authentification "basic" est "digest". Digest n'envoie pas le mot de passe mais un hachage type HA1. Seulement, ce hachage peut tout comme le mot de passe être intercepté et être rejoué pour ouvrir une autre session plus tard. Ok, le vilain intercepteur n'a pas le mot de passe, mais il n'en a pas besoin puisque le hachage qu'il a intercepté lui suffit pour obtenir l'accès. De plus l'authentification "digest" n'est pas supportée par humm... certains butineurs.
Si la sécurité doit être renforcée, il faut alors considérer l'usage de SSL.
-- Léa Gris
Bonjour,
Olivier Masson a écrit :
Attention également au type d'authentification car celle de base,
largement utilisée, fait circuler les identifiants en clair.
Oui olivier, avec une nuance :
L'alternative à l'authentification "basic" est "digest". Digest n'envoie
pas le mot de passe mais un hachage type HA1.
Seulement, ce hachage peut tout comme le mot de passe être intercepté et
être rejoué pour ouvrir une autre session plus tard. Ok, le vilain
intercepteur n'a pas le mot de passe, mais il n'en a pas besoin puisque
le hachage qu'il a intercepté lui suffit pour obtenir l'accès.
De plus l'authentification "digest" n'est pas supportée par humm...
certains butineurs.
Si la sécurité doit être renforcée, il faut alors considérer l'usage de SSL.
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Oui olivier, avec une nuance :
L'alternative à l'authentification "basic" est "digest". Digest n'envoie pas le mot de passe mais un hachage type HA1. Seulement, ce hachage peut tout comme le mot de passe être intercepté et être rejoué pour ouvrir une autre session plus tard. Ok, le vilain intercepteur n'a pas le mot de passe, mais il n'en a pas besoin puisque le hachage qu'il a intercepté lui suffit pour obtenir l'accès. De plus l'authentification "digest" n'est pas supportée par humm... certains butineurs.
Si la sécurité doit être renforcée, il faut alors considérer l'usage de SSL.
-- Léa Gris
Sergio
Olivier Masson a écrit :
Pour une utilisation de ce genre, ça ne me semble pas bien approprié. Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Hummm... Certes, mais l'autre (un formulaire avec login/mdp dans une page non https) est-ce plus sécuritaire ?
Pour une utilisation de ce genre, ça ne me semble pas bien approprié.
Néanmoins, vous pouvez renvoyer un en-tête :
header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base,
largement utilisée, fait circuler les identifiants en clair.
Hummm... Certes, mais l'autre (un formulaire avec login/mdp dans une page non https) est-ce plus sécuritaire ?
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Pour une utilisation de ce genre, ça ne me semble pas bien approprié. Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Hummm... Certes, mais l'autre (un formulaire avec login/mdp dans une page non https) est-ce plus sécuritaire ?
À (at) Mon, 23 Nov 2009 15:50:00 +0100, Sergio écrivait (wrote):
Olivier Masson a écrit :
Pour une utilisation de ce genre, ça ne me semble pas bien approprié. Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Hummm... Certes, mais l'autre (un formulaire avec login/mdp dans une page non https) est-ce plus sécuritaire ?
Je pense qu'Olivier voulait parler des deux méthodes Basic et Digest proposées par HTTP. Aucune des deux n'est sûre même si Digest (lorsqu'elle est utilisable par le navigateur) évite la circulation du mot de passe en clair.
Pour une authentification via un formulaire HTML, s'il y a un script de soumission qui chiffre le couple login/mdp avant de l'envoyer, c'est déjà mieux. Mais cela n'empêche pas une attaque du type man-in-the-middle.
Les seules solutions réellement efficaces passent par HTTPS (ou via un autre moyen de chiffrement des échanges avec certificats).
À (at) Mon, 23 Nov 2009 15:50:00 +0100,
Sergio <serge.laposte@delbono.net.invalid> écrivait (wrote):
Olivier Masson a écrit :
Pour une utilisation de ce genre, ça ne me semble pas bien approprié.
Néanmoins, vous pouvez renvoyer un en-tête :
header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base,
largement utilisée, fait circuler les identifiants en clair.
Hummm... Certes, mais l'autre (un formulaire avec login/mdp dans une
page non https) est-ce plus sécuritaire ?
Je pense qu'Olivier voulait parler des deux méthodes Basic et Digest
proposées par HTTP. Aucune des deux n'est sûre même si Digest
(lorsqu'elle est utilisable par le navigateur) évite la circulation du
mot de passe en clair.
Pour une authentification via un formulaire HTML, s'il y a un script
de soumission qui chiffre le couple login/mdp avant de l'envoyer,
c'est déjà mieux. Mais cela n'empêche pas une attaque du type
man-in-the-middle.
Les seules solutions réellement efficaces passent par HTTPS (ou via un
autre moyen de chiffrement des échanges avec certificats).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Mon, 23 Nov 2009 15:50:00 +0100, Sergio écrivait (wrote):
Olivier Masson a écrit :
Pour une utilisation de ce genre, ça ne me semble pas bien approprié. Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Hummm... Certes, mais l'autre (un formulaire avec login/mdp dans une page non https) est-ce plus sécuritaire ?
Je pense qu'Olivier voulait parler des deux méthodes Basic et Digest proposées par HTTP. Aucune des deux n'est sûre même si Digest (lorsqu'elle est utilisable par le navigateur) évite la circulation du mot de passe en clair.
Pour une authentification via un formulaire HTML, s'il y a un script de soumission qui chiffre le couple login/mdp avant de l'envoyer, c'est déjà mieux. Mais cela n'empêche pas une attaque du type man-in-the-middle.
Les seules solutions réellement efficaces passent par HTTPS (ou via un autre moyen de chiffrement des échanges avec certificats).
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Oui olivier, avec une nuance :
L'alternative à l'authentification "basic" est "digest". Digest n'envoie pas le mot de passe mais un hachage type HA1.
Oui, c'est MD5 (voire SHA1). L'article de wikipedia est incomplet.
Seulement, ce hachage peut tout comme le mot de passe être intercepté et être rejoué pour ouvrir une autre session plus tard. Ok, le vilain intercepteur n'a pas le mot de passe, mais il n'en a pas besoin puisque le hachage qu'il a intercepté lui suffit pour obtenir l'accès. De plus l'authentification "digest" n'est pas supportée par humm... certains butineurs.
Euh... Même IE5.5 fonctionne (je viens de tester, à moins que IETester fausse le test). DIGEST peut être utilisé conjointement avec un challenge. Je n'ai jamais dit que cette méthode était la plus sûre (reste sensible à une attaque MiM) mais elle l'est nettement plus, surtout si on le fait bien, que du Basic. La plupart des PhpMyAdmin, des webalizer et autres awstats, beaucoup d'espaces privés, etc. utilisent une authentification http.
Lea Gris a écrit :
Bonjour,
Olivier Masson a écrit :
Attention également au type d'authentification car celle de base,
largement utilisée, fait circuler les identifiants en clair.
Oui olivier, avec une nuance :
L'alternative à l'authentification "basic" est "digest". Digest n'envoie
pas le mot de passe mais un hachage type HA1.
Oui, c'est MD5 (voire SHA1). L'article de wikipedia est incomplet.
Seulement, ce hachage peut tout comme le mot de passe être intercepté et
être rejoué pour ouvrir une autre session plus tard. Ok, le vilain
intercepteur n'a pas le mot de passe, mais il n'en a pas besoin puisque
le hachage qu'il a intercepté lui suffit pour obtenir l'accès.
De plus l'authentification "digest" n'est pas supportée par humm...
certains butineurs.
Euh... Même IE5.5 fonctionne (je viens de tester, à moins que IETester
fausse le test).
DIGEST peut être utilisé conjointement avec un challenge.
Je n'ai jamais dit que cette méthode était la plus sûre (reste sensible
à une attaque MiM) mais elle l'est nettement plus, surtout si on le fait
bien, que du Basic.
La plupart des PhpMyAdmin, des webalizer et autres awstats, beaucoup
d'espaces privés, etc. utilisent une authentification http.
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
Oui olivier, avec une nuance :
L'alternative à l'authentification "basic" est "digest". Digest n'envoie pas le mot de passe mais un hachage type HA1.
Oui, c'est MD5 (voire SHA1). L'article de wikipedia est incomplet.
Seulement, ce hachage peut tout comme le mot de passe être intercepté et être rejoué pour ouvrir une autre session plus tard. Ok, le vilain intercepteur n'a pas le mot de passe, mais il n'en a pas besoin puisque le hachage qu'il a intercepté lui suffit pour obtenir l'accès. De plus l'authentification "digest" n'est pas supportée par humm... certains butineurs.
Euh... Même IE5.5 fonctionne (je viens de tester, à moins que IETester fausse le test). DIGEST peut être utilisé conjointement avec un challenge. Je n'ai jamais dit que cette méthode était la plus sûre (reste sensible à une attaque MiM) mais elle l'est nettement plus, surtout si on le fait bien, que du Basic. La plupart des PhpMyAdmin, des webalizer et autres awstats, beaucoup d'espaces privés, etc. utilisent une authentification http.
Thierry
"Olivier Masson" a écrit dans le message de news: 4b0a53d4$0$29365$
Thierry a écrit :
Bonsoir,
je restreints l'accès à un site avec htaccess de façon à ce que les utilisateurs s'identifient personnellement. Comment annuler l'identification de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour (afin que la fenêtre d'identification réapparaisse) ?
Bonjour,
Pour une utilisation de ce genre, ça ne me semble pas bien approprié.
c'est juste une solution "de secour" en attendant mieux
Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
j'ai fais des essais mais j'ai un peu de mal pour envoyer l'entête HTTP avec Perl, je passe sur fr.comp.lang.perl pour la suite, merci.
"Olivier Masson" <sisemen@laposte.net> a écrit dans le message de news:
4b0a53d4$0$29365$426a74cc@news.free.fr...
Thierry a écrit :
Bonsoir,
je restreints l'accès à un site avec htaccess de façon à ce que les
utilisateurs s'identifient personnellement. Comment annuler
l'identification de l'utilisateur courant pour qu'un autre puisse
s'identifier à son tour (afin que la fenêtre d'identification
réapparaisse) ?
Bonjour,
Pour une utilisation de ce genre, ça ne me semble pas bien approprié.
c'est juste une solution "de secour" en attendant mieux
Néanmoins, vous pouvez renvoyer un en-tête :
header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base,
largement utilisée, fait circuler les identifiants en clair.
j'ai fais des essais mais j'ai un peu de mal pour envoyer l'entête HTTP avec
Perl, je passe sur fr.comp.lang.perl pour la suite, merci.
"Olivier Masson" a écrit dans le message de news: 4b0a53d4$0$29365$
Thierry a écrit :
Bonsoir,
je restreints l'accès à un site avec htaccess de façon à ce que les utilisateurs s'identifient personnellement. Comment annuler l'identification de l'utilisateur courant pour qu'un autre puisse s'identifier à son tour (afin que la fenêtre d'identification réapparaisse) ?
Bonjour,
Pour une utilisation de ce genre, ça ne me semble pas bien approprié.
c'est juste une solution "de secour" en attendant mieux
Néanmoins, vous pouvez renvoyer un en-tête : header('HTTP/1.0 401 Unauthorized');
Attention également au type d'authentification car celle de base, largement utilisée, fait circuler les identifiants en clair.
j'ai fais des essais mais j'ai un peu de mal pour envoyer l'entête HTTP avec Perl, je passe sur fr.comp.lang.perl pour la suite, merci.