Je voudrais savoir si on peut changer son mot de passe windows (compte
windows non admin) directement a partie d'un serveur sous Linux via des soft
comme Samba par ex.
Je voudrais savoir si on peut changer son mot de passe windows (compte windows non admin) directement a partie d'un serveur sous Linux via des soft comme Samba par ex.
La commande smbpasswd permet de changer le mot de passe d'un utilisateur SMB. L'option -r permet de spécifier la machine distante. Pour plus d'informations sur la commande, consulter le man.
-- David LE BOURGEOIS
La réalité, c'est ce qui refuse de disparaître quand on a cessé d'y croire. -+- Philip Kindred Dick (1928-1982) -+-
Salut,
Bonsoir.
Je voudrais savoir si on peut changer son mot de passe windows (compte
windows non admin) directement a partie d'un serveur sous Linux via des soft
comme Samba par ex.
La commande smbpasswd permet de changer le mot de passe d'un utilisateur
SMB. L'option -r permet de spécifier la machine distante.
Pour plus d'informations sur la commande, consulter le man.
--
David LE BOURGEOIS
La réalité, c'est ce qui refuse de disparaître
quand on a cessé d'y croire.
-+- Philip Kindred Dick (1928-1982) -+-
Je voudrais savoir si on peut changer son mot de passe windows (compte windows non admin) directement a partie d'un serveur sous Linux via des soft comme Samba par ex.
La commande smbpasswd permet de changer le mot de passe d'un utilisateur SMB. L'option -r permet de spécifier la machine distante. Pour plus d'informations sur la commande, consulter le man.
-- David LE BOURGEOIS
La réalité, c'est ce qui refuse de disparaître quand on a cessé d'y croire. -+- Philip Kindred Dick (1928-1982) -+-
MChrisM
Merci de la reactivite, je pense que cette commande sera sous peu testee et utilisee... :-)
Je connaissais la methode dans le sens Windows->Linux mais pas reciproquement
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
"David LE BOURGEOIS" wrote in message news:420e582e$0$520$
Salut,
Bonsoir.
Je voudrais savoir si on peut changer son mot de passe windows (compte windows non admin) directement a partie d'un serveur sous Linux via des soft comme Samba par ex.
La commande smbpasswd permet de changer le mot de passe d'un utilisateur SMB. L'option -r permet de spécifier la machine distante. Pour plus d'informations sur la commande, consulter le man.
-- David LE BOURGEOIS
La réalité, c'est ce qui refuse de disparaître quand on a cessé d'y croire. -+- Philip Kindred Dick (1928-1982) -+-
Merci de la reactivite, je pense que cette commande sera sous peu testee et
utilisee... :-)
Je connaissais la methode dans le sens Windows->Linux mais pas
reciproquement
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe
circule en clair sur le reseau quand je vais modifier mon pass Windows via
Linux ?
"David LE BOURGEOIS" <this.address@is.invalid> wrote in message
news:420e582e$0$520$626a14ce@news.free.fr...
Salut,
Bonsoir.
Je voudrais savoir si on peut changer son mot de passe windows (compte
windows non admin) directement a partie d'un serveur sous Linux via des
soft comme Samba par ex.
La commande smbpasswd permet de changer le mot de passe d'un utilisateur
SMB. L'option -r permet de spécifier la machine distante.
Pour plus d'informations sur la commande, consulter le man.
--
David LE BOURGEOIS
La réalité, c'est ce qui refuse de disparaître
quand on a cessé d'y croire.
-+- Philip Kindred Dick (1928-1982) -+-
Merci de la reactivite, je pense que cette commande sera sous peu testee et utilisee... :-)
Je connaissais la methode dans le sens Windows->Linux mais pas reciproquement
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
"David LE BOURGEOIS" wrote in message news:420e582e$0$520$
Salut,
Bonsoir.
Je voudrais savoir si on peut changer son mot de passe windows (compte windows non admin) directement a partie d'un serveur sous Linux via des soft comme Samba par ex.
La commande smbpasswd permet de changer le mot de passe d'un utilisateur SMB. L'option -r permet de spécifier la machine distante. Pour plus d'informations sur la commande, consulter le man.
-- David LE BOURGEOIS
La réalité, c'est ce qui refuse de disparaître quand on a cessé d'y croire. -+- Philip Kindred Dick (1928-1982) -+-
David LE BOURGEOIS
Merci de la reactivite, je pense que cette commande sera sous peu testee et utilisee... :-)
Je connaissais la methode dans le sens Windows->Linux mais pas reciproquement
Je suppose que, le protocole étant commun au deux systèmes, il n'y a aucune raison pour que cela ne fonctionne pas dans les deux sens.
Par contre, je sais qu'il faut aligner la version de Samba avec celle de Windows. Je me rappelle avoir été obligé de passer en Samba 3.0 (>2.2.8) pour joindre un poste Windows 2000 à un domaine.
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
Du côté de samba il existe une option encrypt password, et sous Windows je crois qu'une valeur de clé est à changer dans la base de registres.
Pour ma part je n'ai pas de serveur Windows et mon contrôleur de domaine est Samba.
J'ai effectué un changement de mot de passe depuis une machine linux cliente (smbpasswd -r pdc.maison -U david), en écoutant avec ethereal sur le serveur. Le mot de passe ne transite pas en clair.
-- David LE BOURGEOIS
20:20 Luce et Henri installent nmap : luce: "MAIS NON, faut faire un ./configure --enable-raw-socket, comme CA, LÀ !" henri: "MAIS TU SAIS MEME PAS CE QUE C'EST un raw socket !" luce: "et TOI tu sais ce que c'est un telnet sur le port 25 ?"
Merci de la reactivite, je pense que cette commande sera sous peu testee et
utilisee... :-)
Je connaissais la methode dans le sens Windows->Linux mais pas
reciproquement
Je suppose que, le protocole étant commun au deux systèmes, il n'y a
aucune raison pour que cela ne fonctionne pas dans les deux sens.
Par contre, je sais qu'il faut aligner la version de Samba avec celle de
Windows. Je me rappelle avoir été obligé de passer en Samba 3.0 (>2.2.8)
pour joindre un poste Windows 2000 à un domaine.
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe
circule en clair sur le reseau quand je vais modifier mon pass Windows via
Linux ?
Du côté de samba il existe une option encrypt password, et sous Windows
je crois qu'une valeur de clé est à changer dans la base de registres.
Pour ma part je n'ai pas de serveur Windows et mon contrôleur de domaine
est Samba.
J'ai effectué un changement de mot de passe depuis une machine linux
cliente (smbpasswd -r pdc.maison -U david), en écoutant avec ethereal
sur le serveur. Le mot de passe ne transite pas en clair.
--
David LE BOURGEOIS
20:20 Luce et Henri installent nmap :
luce: "MAIS NON, faut faire un ./configure --enable-raw-socket,
comme CA, LÀ !"
henri: "MAIS TU SAIS MEME PAS CE QUE C'EST un raw socket !"
luce: "et TOI tu sais ce que c'est un telnet sur le port 25 ?"
Merci de la reactivite, je pense que cette commande sera sous peu testee et utilisee... :-)
Je connaissais la methode dans le sens Windows->Linux mais pas reciproquement
Je suppose que, le protocole étant commun au deux systèmes, il n'y a aucune raison pour que cela ne fonctionne pas dans les deux sens.
Par contre, je sais qu'il faut aligner la version de Samba avec celle de Windows. Je me rappelle avoir été obligé de passer en Samba 3.0 (>2.2.8) pour joindre un poste Windows 2000 à un domaine.
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
Du côté de samba il existe une option encrypt password, et sous Windows je crois qu'une valeur de clé est à changer dans la base de registres.
Pour ma part je n'ai pas de serveur Windows et mon contrôleur de domaine est Samba.
J'ai effectué un changement de mot de passe depuis une machine linux cliente (smbpasswd -r pdc.maison -U david), en écoutant avec ethereal sur le serveur. Le mot de passe ne transite pas en clair.
-- David LE BOURGEOIS
20:20 Luce et Henri installent nmap : luce: "MAIS NON, faut faire un ./configure --enable-raw-socket, comme CA, LÀ !" henri: "MAIS TU SAIS MEME PAS CE QUE C'EST un raw socket !" luce: "et TOI tu sais ce que c'est un telnet sur le port 25 ?"
vincent.verdon
Dans les versions actuelles de Samba, les mots de passe circulent cryptés.
Amicalement, Vincent Verdon
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
Dans les versions actuelles de Samba, les mots de passe circulent cryptés.
Amicalement, Vincent Verdon
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de
passe circule en clair sur le reseau quand je vais modifier mon pass
Windows via Linux ?
Dans les versions actuelles de Samba, les mots de passe circulent cryptés.
Amicalement, Vincent Verdon
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
l'indien
On Tue, 22 Feb 2005 22:55:01 +0100, wrote:
Dans les versions actuelles de Samba, les mots de passe circulent cryptés.
Le mot de passe circule encore ? J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS à inventé le protocole CHAP pour justement éviter que les mots de passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba, j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
On Tue, 22 Feb 2005 22:55:01 +0100, vincent.verdon@laposte.net wrote:
Dans les versions actuelles de Samba, les mots de passe circulent cryptés.
Le mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS
à inventé le protocole CHAP pour justement éviter que les mots de
passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba,
j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de
passe circule en clair sur le reseau quand je vais modifier mon pass
Windows via Linux ?
Dans les versions actuelles de Samba, les mots de passe circulent cryptés.
Le mot de passe circule encore ? J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS à inventé le protocole CHAP pour justement éviter que les mots de passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba, j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Je ne suis pas sur (faudrait "ethereal-er"), mais est-ce que le mot de passe circule en clair sur le reseau quand je vais modifier mon pass Windows via Linux ?
vincent.verdon
Dans la mesure ou on vient controler les utilisateur sur un serveur de domaine, il faut bien à un moment donné que les mots de passes circulent, mais cryptés.
mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS à inventé le protocole CHAP pour justement éviter que les mots de passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba, j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Dans la mesure ou on vient controler les utilisateur sur un serveur de
domaine, il faut bien à un moment donné que les mots de passes
circulent, mais cryptés.
mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS
à inventé le protocole CHAP pour justement éviter que les mots de
passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba,
j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Dans la mesure ou on vient controler les utilisateur sur un serveur de domaine, il faut bien à un moment donné que les mots de passes circulent, mais cryptés.
mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS à inventé le protocole CHAP pour justement éviter que les mots de passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba, j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
l'indien
On Fri, 25 Feb 2005 20:59:04 +0100, wrote:
Dans la mesure ou on vient controler les utilisateur sur un serveur de domaine, il faut bien à un moment donné que les mots de passes circulent, mais cryptés.
Non. L'idée du CHAP, qui est utilisée dans pas mal de protocoles d'identifications. Le nom du protocole est "challenge authentification protocol". Comme son nom l'indique, le serveur lance un challenge au client que celui-ci ne peut réussir que s'il possède le bon mot de passe: le serveur envoie un message à son client. Ce message est alléatoire. De son coté, il le transforme avec une moulinette prenant le mot de passe et ce message alléatoire comme paramêtres. Le client fait de même et envoie le résultat au serveur. Si le résultat renvoyé est le même que celui qu'a calculé le serveur, c'est que le client a le bon mot de passe. C'est simple et ça ne nécessite à aucun moment de faire transiter le mot de passe par le réseau. De plus, comme le résultat du challenge dépend du message alléatoire envoyé par le serveur, il est impossible à un "man in the middle" qui ne connait pas le mot de passe de répondre à la place du client puisqu'il ne peut pas deviner quelle est la bonne réponse au challenge. Bien sur, celà suppose que la "moulinette" utilisée aient de bonnes propriété cryptographiques, c'est à dire qu'on ne peut pas deviner la réponse à un challenge en connaissant les réponses aux challenges précédents: celà garanti alors que ton challenge et la réponse peuvent transiter par des réseaux non protégés et potentiellement espionnés (comme Internet) sans danger.
mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS à inventé le protocole CHAP pour justement éviter que les mots de passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba, j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
On Fri, 25 Feb 2005 20:59:04 +0100, vincent.verdon@laposte.net wrote:
Dans la mesure ou on vient controler les utilisateur sur un serveur de
domaine, il faut bien à un moment donné que les mots de passes
circulent, mais cryptés.
Non.
L'idée du CHAP, qui est utilisée dans pas mal de protocoles
d'identifications. Le nom du protocole est "challenge authentification
protocol". Comme son nom l'indique, le serveur lance un challenge au
client que celui-ci ne peut réussir que s'il possède le bon mot de
passe:
le serveur envoie un message à son client. Ce message est alléatoire.
De son coté, il le transforme avec une moulinette prenant le mot de passe
et ce message alléatoire comme paramêtres. Le client fait de même et
envoie le résultat au serveur. Si le résultat renvoyé est le même que
celui qu'a calculé le serveur, c'est que le client a le bon mot de passe.
C'est simple et ça ne nécessite à aucun moment de faire transiter le
mot de passe par le réseau. De plus, comme le résultat du challenge
dépend du message alléatoire envoyé par le serveur, il est impossible
à un "man in the middle" qui ne connait pas le mot de passe de répondre
à la place du client puisqu'il ne peut pas deviner quelle est la bonne
réponse au challenge. Bien sur, celà suppose que la "moulinette"
utilisée aient de bonnes propriété cryptographiques, c'est à dire
qu'on ne peut pas deviner la réponse à un challenge en connaissant les
réponses aux challenges précédents: celà garanti alors que ton
challenge et la réponse peuvent transiter par des réseaux non protégés
et potentiellement espionnés (comme Internet) sans danger.
mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS
à inventé le protocole CHAP pour justement éviter que les mots de
passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba,
j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Dans la mesure ou on vient controler les utilisateur sur un serveur de domaine, il faut bien à un moment donné que les mots de passes circulent, mais cryptés.
Non. L'idée du CHAP, qui est utilisée dans pas mal de protocoles d'identifications. Le nom du protocole est "challenge authentification protocol". Comme son nom l'indique, le serveur lance un challenge au client que celui-ci ne peut réussir que s'il possède le bon mot de passe: le serveur envoie un message à son client. Ce message est alléatoire. De son coté, il le transforme avec une moulinette prenant le mot de passe et ce message alléatoire comme paramêtres. Le client fait de même et envoie le résultat au serveur. Si le résultat renvoyé est le même que celui qu'a calculé le serveur, c'est que le client a le bon mot de passe. C'est simple et ça ne nécessite à aucun moment de faire transiter le mot de passe par le réseau. De plus, comme le résultat du challenge dépend du message alléatoire envoyé par le serveur, il est impossible à un "man in the middle" qui ne connait pas le mot de passe de répondre à la place du client puisqu'il ne peut pas deviner quelle est la bonne réponse au challenge. Bien sur, celà suppose que la "moulinette" utilisée aient de bonnes propriété cryptographiques, c'est à dire qu'on ne peut pas deviner la réponse à un challenge en connaissant les réponses aux challenges précédents: celà garanti alors que ton challenge et la réponse peuvent transiter par des réseaux non protégés et potentiellement espionnés (comme Internet) sans danger.
mot de passe circule encore ?
J'éspère que non. Ca ferait mauvais genre, surtout quand on sait que MS à inventé le protocole CHAP pour justement éviter que les mots de passes ne circulent ! Même si ce protocole n'a pas de rapport avec Samba, j'éspère qu'ils ont continué à appliquer cette (bonne !) idée !
Nicolas George
l'indien wrote in message :
C'est simple et ça ne nécessite à aucun moment de faire transiter le mot de passe par le réseau.
En revanche, ça nécessite que le serveur ait le mot de passe en clair quelque part, ce qu'on peut souhaiter éviter. Hélas, la seule solution pour avoir les deux, c'est la crypto asymétrique, qui est largement plus compliquée.
De plus, comme le résultat du challenge dépend du message alléatoire envoyé par le serveur, il est impossible à un "man in the middle" qui ne connait pas le mot de passe de répondre à la place du client puisqu'il ne peut pas deviner quelle est la bonne réponse au challenge.
Tu te trompes : un « man in the middle », comme son nom l'indique, il est « in the middle », il fait passer le challenge du serveur au client, et le la réponse du client au serveur, puis peut contrôler à sa guise la connexion. Ce qu'empêche ce protocole, c'est qu'un espion puisse réutiliser l'authentification d'une connexion pour une nouvelle connexion.
l'indien wrote in message <pan.2005.02.26.00.38.08.373086@magic.fr>:
C'est simple et ça ne nécessite à aucun moment de faire transiter le
mot de passe par le réseau.
En revanche, ça nécessite que le serveur ait le mot de passe en clair
quelque part, ce qu'on peut souhaiter éviter. Hélas, la seule solution pour
avoir les deux, c'est la crypto asymétrique, qui est largement plus
compliquée.
De plus, comme le résultat du challenge
dépend du message alléatoire envoyé par le serveur, il est impossible
à un "man in the middle" qui ne connait pas le mot de passe de répondre
à la place du client puisqu'il ne peut pas deviner quelle est la bonne
réponse au challenge.
Tu te trompes : un « man in the middle », comme son nom l'indique, il est
« in the middle », il fait passer le challenge du serveur au client, et le
la réponse du client au serveur, puis peut contrôler à sa guise la
connexion. Ce qu'empêche ce protocole, c'est qu'un espion puisse réutiliser
l'authentification d'une connexion pour une nouvelle connexion.
C'est simple et ça ne nécessite à aucun moment de faire transiter le mot de passe par le réseau.
En revanche, ça nécessite que le serveur ait le mot de passe en clair quelque part, ce qu'on peut souhaiter éviter. Hélas, la seule solution pour avoir les deux, c'est la crypto asymétrique, qui est largement plus compliquée.
De plus, comme le résultat du challenge dépend du message alléatoire envoyé par le serveur, il est impossible à un "man in the middle" qui ne connait pas le mot de passe de répondre à la place du client puisqu'il ne peut pas deviner quelle est la bonne réponse au challenge.
Tu te trompes : un « man in the middle », comme son nom l'indique, il est « in the middle », il fait passer le challenge du serveur au client, et le la réponse du client au serveur, puis peut contrôler à sa guise la connexion. Ce qu'empêche ce protocole, c'est qu'un espion puisse réutiliser l'authentification d'une connexion pour une nouvelle connexion.
l'indien
On Sat, 26 Feb 2005 14:29:57 +0000, Nicolas George wrote:
l'indien wrote in message :
C'est simple et ça ne nécessite à aucun moment de faire transiter le mot de passe par le réseau.
En revanche, ça nécessite que le serveur ait le mot de passe en clair quelque part, ce qu'on peut souhaiter éviter. Hélas, la seule solution pour avoir les deux, c'est la crypto asymétrique, qui est largement plus compliquée.
Non, absolument pas. Un mot de passe hashé, comme celui des shadow passwords marche parfaitement avec cette méthode. Le fait de stocker le mot de passe en clair ou dans une forme hashée est un autre problème, complètement indépendant.
De plus, comme le résultat du challenge dépend du message alléatoire envoyé par le serveur, il est impossible à un "man in the middle" qui ne connait pas le mot de passe de répondre à la place du client puisqu'il ne peut pas deviner quelle est la bonne réponse au challenge.
Tu te trompes : un « man in the middle », comme son nom l'indique, il est « in the middle », il fait passer le challenge du serveur au client, et le la réponse du client au serveur, puis peut contrôler à sa guise la connexion. Ce qu'empêche ce protocole, c'est qu'un espion puisse réutiliser l'authentification d'une connexion pour une nouvelle connexion.
Effectivement, c'est bien ce que je voulais dire.
On Sat, 26 Feb 2005 14:29:57 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.02.26.00.38.08.373086@magic.fr>:
C'est simple et ça ne nécessite à aucun moment de faire transiter le
mot de passe par le réseau.
En revanche, ça nécessite que le serveur ait le mot de passe en clair
quelque part, ce qu'on peut souhaiter éviter. Hélas, la seule solution pour
avoir les deux, c'est la crypto asymétrique, qui est largement plus
compliquée.
Non, absolument pas. Un mot de passe hashé, comme celui des shadow
passwords marche parfaitement avec cette méthode. Le fait de stocker le
mot de passe en clair ou dans une forme hashée est un autre problème,
complètement indépendant.
De plus, comme le résultat du challenge
dépend du message alléatoire envoyé par le serveur, il est impossible
à un "man in the middle" qui ne connait pas le mot de passe de répondre
à la place du client puisqu'il ne peut pas deviner quelle est la bonne
réponse au challenge.
Tu te trompes : un « man in the middle », comme son nom l'indique, il est
« in the middle », il fait passer le challenge du serveur au client, et le
la réponse du client au serveur, puis peut contrôler à sa guise la
connexion. Ce qu'empêche ce protocole, c'est qu'un espion puisse réutiliser
l'authentification d'une connexion pour une nouvelle connexion.
On Sat, 26 Feb 2005 14:29:57 +0000, Nicolas George wrote:
l'indien wrote in message :
C'est simple et ça ne nécessite à aucun moment de faire transiter le mot de passe par le réseau.
En revanche, ça nécessite que le serveur ait le mot de passe en clair quelque part, ce qu'on peut souhaiter éviter. Hélas, la seule solution pour avoir les deux, c'est la crypto asymétrique, qui est largement plus compliquée.
Non, absolument pas. Un mot de passe hashé, comme celui des shadow passwords marche parfaitement avec cette méthode. Le fait de stocker le mot de passe en clair ou dans une forme hashée est un autre problème, complètement indépendant.
De plus, comme le résultat du challenge dépend du message alléatoire envoyé par le serveur, il est impossible à un "man in the middle" qui ne connait pas le mot de passe de répondre à la place du client puisqu'il ne peut pas deviner quelle est la bonne réponse au challenge.
Tu te trompes : un « man in the middle », comme son nom l'indique, il est « in the middle », il fait passer le challenge du serveur au client, et le la réponse du client au serveur, puis peut contrôler à sa guise la connexion. Ce qu'empêche ce protocole, c'est qu'un espion puisse réutiliser l'authentification d'une connexion pour une nouvelle connexion.
Effectivement, c'est bien ce que je voulais dire.
Nicolas George
l'indien wrote in message :
Non, absolument pas. Un mot de passe hashé, comme celui des shadow passwords marche parfaitement avec cette méthode. Le fait de stocker le mot de passe en clair ou dans une forme hashée est un autre problème, complètement indépendant.
Non, ça ne marche pas : il faut le mot de passe en clair pour calculer la valeur du challenge. En fait, ce n'est pas tout à fait exact, mais il faut au serveur quelque chose _en clair_ qui lui permette de calculer la réponse. Ce n'est pas forcément le mot de passe lui-même, car la fonction de challenge peut commencer par touiller le mot de passe avant de le mélanger au challenge, mais c'est une information qui est forcément suffisante pour réussir le challenge.
En d'autres termes, si je parviens à savoir ce que le serveur sait du mot de passe d'un utilisateur, je n'en saurai pas forcément assez pour m'authentifier en tant que A sur un système complètement différent mais où A aurait utilisé le même mot de passe, mais j'en saurai forcément assez pour m'authentifier auprès du serveur en tant que A.
Les shadow-passwords et similaires donnent moins d'information que ça : si je te dis que mon mot de passe dans shadow est « $1$$PjsCIhRcjpb1ItINbbHv2. », tu n'as pas assez d'information pour t'authentifier en tant que moi (à moins de trouver une collision dans la fonciton de hash, évidemment).
l'indien wrote in message <pan.2005.02.26.15.54.54.389357@magic.fr>:
Non, absolument pas. Un mot de passe hashé, comme celui des shadow
passwords marche parfaitement avec cette méthode. Le fait de stocker le
mot de passe en clair ou dans une forme hashée est un autre problème,
complètement indépendant.
Non, ça ne marche pas : il faut le mot de passe en clair pour calculer la
valeur du challenge. En fait, ce n'est pas tout à fait exact, mais il faut
au serveur quelque chose _en clair_ qui lui permette de calculer la réponse.
Ce n'est pas forcément le mot de passe lui-même, car la fonction de
challenge peut commencer par touiller le mot de passe avant de le mélanger
au challenge, mais c'est une information qui est forcément suffisante pour
réussir le challenge.
En d'autres termes, si je parviens à savoir ce que le serveur sait du mot de
passe d'un utilisateur, je n'en saurai pas forcément assez pour
m'authentifier en tant que A sur un système complètement différent mais où A
aurait utilisé le même mot de passe, mais j'en saurai forcément assez pour
m'authentifier auprès du serveur en tant que A.
Les shadow-passwords et similaires donnent moins d'information que ça : si
je te dis que mon mot de passe dans shadow est
« $1$$PjsCIhRcjpb1ItINbbHv2. », tu n'as pas assez d'information pour
t'authentifier en tant que moi (à moins de trouver une collision dans la
fonciton de hash, évidemment).
Non, absolument pas. Un mot de passe hashé, comme celui des shadow passwords marche parfaitement avec cette méthode. Le fait de stocker le mot de passe en clair ou dans une forme hashée est un autre problème, complètement indépendant.
Non, ça ne marche pas : il faut le mot de passe en clair pour calculer la valeur du challenge. En fait, ce n'est pas tout à fait exact, mais il faut au serveur quelque chose _en clair_ qui lui permette de calculer la réponse. Ce n'est pas forcément le mot de passe lui-même, car la fonction de challenge peut commencer par touiller le mot de passe avant de le mélanger au challenge, mais c'est une information qui est forcément suffisante pour réussir le challenge.
En d'autres termes, si je parviens à savoir ce que le serveur sait du mot de passe d'un utilisateur, je n'en saurai pas forcément assez pour m'authentifier en tant que A sur un système complètement différent mais où A aurait utilisé le même mot de passe, mais j'en saurai forcément assez pour m'authentifier auprès du serveur en tant que A.
Les shadow-passwords et similaires donnent moins d'information que ça : si je te dis que mon mot de passe dans shadow est « $1$$PjsCIhRcjpb1ItINbbHv2. », tu n'as pas assez d'information pour t'authentifier en tant que moi (à moins de trouver une collision dans la fonciton de hash, évidemment).
