Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Annuler identif. par htaccess

7 réponses
Avatar
Thierry
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) ?

7 réponses

Avatar
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.
Avatar
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.
Avatar
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
Avatar
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 ?

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Avatar
Paul 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).

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/&gt;
Avatar
Olivier Masson
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.
Avatar
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.