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