Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Annuler identif. par htaccess

0 views
Skip to first unread message

Thierry

unread,
Nov 22, 2009, 4:36:23 PM11/22/09
to
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) ?


Olivier Masson

unread,
Nov 23, 2009, 4:20:09 AM11/23/09
to
Thierry a �crit :

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

unread,
Nov 23, 2009, 5:11:40 AM11/23/09
to

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

unread,
Nov 23, 2009, 9:05:15 AM11/23/09
to
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

Sergio

unread,
Nov 23, 2009, 9:50:00 AM11/23/09
to
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

Paul Gaborit

unread,
Nov 23, 2009, 10:14:27 AM11/23/09
to

� (at) Mon, 23 Nov 2009 15:50:00 +0100,
Sergio <serge....@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/>

Olivier Masson

unread,
Nov 23, 2009, 10:21:21 AM11/23/09
to
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.

Thierry

unread,
Nov 24, 2009, 12:03:02 PM11/24/09
to
"Olivier Masson" <sis...@laposte.net> a �crit dans le message de news:
4b0a53d4$0$29365$426a...@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.


0 new messages