je m'intéresse à ssh et j'ai constaté cela dans la RFC:
http://www.ietf.org/rfc/rfc4252.txt
8. Password Authentication Method: "password"
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.
Donc le mot de passe est envoyé en clair (dans un canal chiffré,
toutefois); ceci est confirmé par:
Note that even though the cleartext password is transmitted in the
packet, the entire packet is encrypted by the transport layer.
Ce qui signifie que si je met en place un faux serveur ssh, je
peux récupérer très facilement le couple login/pass d'un utilisateur!
(Utilisateur suffisement distrait au point de ne pas se rendre compte
que la clé de l'hôte distant à changé[1]).
Ma question est la suivante: pourquoi avoir laissé transiter le
mot de passe en clair, et non pas demander un hash (ou un autre
procédé crypto, lequel?) de celui-ci afin que l'attaquant qui
mette en place ce type de serveur ne récupère pas le password en
clair. Ceci semblerait plus sûr en première analyse.
Mais à la réflexion, rien n'empêche l'attaquant d'ouvrir en parrallèle
une connexion vers le véritable serveur ssh et faire suivre les
requêtes imaginables au paragraphe précédent. Ceci complexifie le
code de l'attaquant, mais reste possible. Ce qui revient à dire que
demander un hash au lieu d'un mot de passe en clair ne sécurise pas
réellement la connexion du client! Et donc, autant envoyer en clair
le mot de passe...
Donc, est il possible de mettre en place une méthode afin qu'un
attaquant ne puisse pas interférer sur une connexion ssh, ou à tout
le moins ne pas récupérer le mot de passe de l'utilisateur?
N'y a t'il pas de solution pour protéger le mot de passe de
l'utilisateur distrait?
Merci
[1]Exemple constaté de très nombreuses fois, les users se connectent
depuis windows avec putty qui prévient que la clé de l'hôte change,
et permet de se connecter tout de même en cliquant OK, ce que font
tous les utilisateurs, mais c'est un autre débat.
--
Kevin
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
Erwan David
Kevin Denis écrivait :
Bonjour,
je m'intéresse à ssh et j'ai constaté cela dans la RFC: http://www.ietf.org/rfc/rfc4252.txt 8. Password Authentication Method: "password" Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. Donc le mot de passe est envoyé en clair (dans un canal chiffré, toutefois); ceci est confirmé par: Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Ce qui signifie que si je met en place un faux serveur ssh, je peux récupérer très facilement le couple login/pass d'un utilisateur! (Utilisateur suffisement distrait au point de ne pas se rendre compte que la clé de l'hôte distant à changé[1]).
Ma question est la suivante: pourquoi avoir laissé transiter le mot de passe en clair, et non pas demander un hash (ou un autre procédé crypto, lequel?) de celui-ci afin que l'attaquant qui mette en place ce type de serveur ne récupère pas le password en clair. Ceci semblerait plus sûr en première analyse.
Ben ça dépend des backend d'authentification, mais tu en a quand même de très utilisés qui demandent le mot de passe en clair. (les mot de passe Unix traditionnels par exemple).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Kevin Denis <kevin@nowhere.invalid> écrivait :
Bonjour,
je m'intéresse à ssh et j'ai constaté cela dans la RFC:
http://www.ietf.org/rfc/rfc4252.txt
8. Password Authentication Method: "password"
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.
Donc le mot de passe est envoyé en clair (dans un canal chiffré,
toutefois); ceci est confirmé par:
Note that even though the cleartext password is transmitted in the
packet, the entire packet is encrypted by the transport layer.
Ce qui signifie que si je met en place un faux serveur ssh, je
peux récupérer très facilement le couple login/pass d'un utilisateur!
(Utilisateur suffisement distrait au point de ne pas se rendre compte
que la clé de l'hôte distant à changé[1]).
Ma question est la suivante: pourquoi avoir laissé transiter le
mot de passe en clair, et non pas demander un hash (ou un autre
procédé crypto, lequel?) de celui-ci afin que l'attaquant qui
mette en place ce type de serveur ne récupère pas le password en
clair. Ceci semblerait plus sûr en première analyse.
Ben ça dépend des backend d'authentification, mais tu en a quand même de
très utilisés qui demandent le mot de passe en clair. (les mot de passe
Unix traditionnels par exemple).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
je m'intéresse à ssh et j'ai constaté cela dans la RFC: http://www.ietf.org/rfc/rfc4252.txt 8. Password Authentication Method: "password" Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. Donc le mot de passe est envoyé en clair (dans un canal chiffré, toutefois); ceci est confirmé par: Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Ce qui signifie que si je met en place un faux serveur ssh, je peux récupérer très facilement le couple login/pass d'un utilisateur! (Utilisateur suffisement distrait au point de ne pas se rendre compte que la clé de l'hôte distant à changé[1]).
Ma question est la suivante: pourquoi avoir laissé transiter le mot de passe en clair, et non pas demander un hash (ou un autre procédé crypto, lequel?) de celui-ci afin que l'attaquant qui mette en place ce type de serveur ne récupère pas le password en clair. Ceci semblerait plus sûr en première analyse.
Ben ça dépend des backend d'authentification, mais tu en a quand même de très utilisés qui demandent le mot de passe en clair. (les mot de passe Unix traditionnels par exemple).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas Pornin
According to Kevin Denis :
Donc, est il possible de mettre en place une méthode afin qu'un attaquant ne puisse pas interférer sur une connexion ssh, ou à tout le moins ne pas récupérer le mot de passe de l'utilisateur? N'y a t'il pas de solution pour protéger le mot de passe de l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même une propriété intéressante, qui est que le serveur n'a pas besoin de stocker le mot de passe, seulement une forme "hachée" (mais pas avec n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
--Thomas Pornin
(*) Bellovin et Merritt ont déposé un brevet, qui devrait se terminer l'an prochain, en 2012. Il est possible que le domaine soit un peu "miné". GnuTLS implémente TLS+SRP et l'existence potentielle de brevets n'a pas l'air de les troubler outre mesure.
According to Kevin Denis <kevin@alinto.comNOSPAM>:
Donc, est il possible de mettre en place une méthode afin qu'un
attaquant ne puisse pas interférer sur une connexion ssh, ou à tout
le moins ne pas récupérer le mot de passe de l'utilisateur?
N'y a t'il pas de solution pour protéger le mot de passe de
l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE
(Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au
lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange")
décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié
par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique"
et n'a pas besoin d'être joué dans un tunnel pré-établi. Les
caractéristiques sont assez "magiques" : à l'issue du protocole, le
client et le serveur se sont authentifiés mutuellement, relativement à
leur connaissance du mot de passe, et ont une clé secrète commune de
forte entropie (qu'on peut utiliser pour chiffer symmétriquement la
suite de la conversation). Néanmoins, un faux serveur ou un faux client
n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même
une propriété intéressante, qui est que le serveur n'a pas besoin de
stocker le mot de passe, seulement une forme "hachée" (mais pas avec
n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 :
http://tools.ietf.org/html/rfc5054
(on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
--Thomas Pornin
(*) Bellovin et Merritt ont déposé un brevet, qui devrait se terminer
l'an prochain, en 2012. Il est possible que le domaine soit un peu
"miné". GnuTLS implémente TLS+SRP et l'existence potentielle de brevets
n'a pas l'air de les troubler outre mesure.
Donc, est il possible de mettre en place une méthode afin qu'un attaquant ne puisse pas interférer sur une connexion ssh, ou à tout le moins ne pas récupérer le mot de passe de l'utilisateur? N'y a t'il pas de solution pour protéger le mot de passe de l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même une propriété intéressante, qui est que le serveur n'a pas besoin de stocker le mot de passe, seulement une forme "hachée" (mais pas avec n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
--Thomas Pornin
(*) Bellovin et Merritt ont déposé un brevet, qui devrait se terminer l'an prochain, en 2012. Il est possible que le domaine soit un peu "miné". GnuTLS implémente TLS+SRP et l'existence potentielle de brevets n'a pas l'air de les troubler outre mesure.
Erwan David
Thomas Pornin écrivait :
According to Kevin Denis :
Donc, est il possible de mettre en place une méthode afin qu'un attaquant ne puisse pas interférer sur une connexion ssh, ou à tout le moins ne pas récupérer le mot de passe de l'utilisateur? N'y a t'il pas de solution pour protéger le mot de passe de l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même une propriété intéressante, qui est que le serveur n'a pas besoin de stocker le mot de passe, seulement une forme "hachée" (mais pas avec n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
--Thomas Pornin
Très intéressant, mais en tant qu'admmin, j'ajoute qu'il va falloir pouvoir intégré ça à du kerberos, ou de l'authentification LDAP, etc...
Bref ça va pas être simple.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas Pornin <pornin@bolet.org> écrivait :
According to Kevin Denis <kevin@alinto.comNOSPAM>:
Donc, est il possible de mettre en place une méthode afin qu'un
attaquant ne puisse pas interférer sur une connexion ssh, ou à tout
le moins ne pas récupérer le mot de passe de l'utilisateur?
N'y a t'il pas de solution pour protéger le mot de passe de
l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE
(Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au
lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange")
décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié
par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique"
et n'a pas besoin d'être joué dans un tunnel pré-établi. Les
caractéristiques sont assez "magiques" : à l'issue du protocole, le
client et le serveur se sont authentifiés mutuellement, relativement à
leur connaissance du mot de passe, et ont une clé secrète commune de
forte entropie (qu'on peut utiliser pour chiffer symmétriquement la
suite de la conversation). Néanmoins, un faux serveur ou un faux client
n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même
une propriété intéressante, qui est que le serveur n'a pas besoin de
stocker le mot de passe, seulement une forme "hachée" (mais pas avec
n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 :
http://tools.ietf.org/html/rfc5054
(on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
--Thomas Pornin
Très intéressant, mais en tant qu'admmin, j'ajoute qu'il va falloir
pouvoir intégré ça à du kerberos, ou de l'authentification LDAP, etc...
Bref ça va pas être simple.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Donc, est il possible de mettre en place une méthode afin qu'un attaquant ne puisse pas interférer sur une connexion ssh, ou à tout le moins ne pas récupérer le mot de passe de l'utilisateur? N'y a t'il pas de solution pour protéger le mot de passe de l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même une propriété intéressante, qui est que le serveur n'a pas besoin de stocker le mot de passe, seulement une forme "hachée" (mais pas avec n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
--Thomas Pornin
Très intéressant, mais en tant qu'admmin, j'ajoute qu'il va falloir pouvoir intégré ça à du kerberos, ou de l'authentification LDAP, etc...
Bref ça va pas être simple.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Kevin Denis
Le 17-01-2011, Thomas Pornin a écrit :
Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Je vais lire, merci.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"? -- Kevin
Le 17-01-2011, Thomas Pornin <pornin@bolet.org> a écrit :
Néanmoins, un faux serveur ou un faux client
n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
SRP est intégré dans SSL/TLS, cf RFC 5054 :
http://tools.ietf.org/html/rfc5054
(on attend que les browsers Web veuillent bien l'implémenter).
Je vais lire, merci.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
Trivialement, rien n'empêche le serveur de fournir le salt au client,
qui va s'en servir pour hacher son mot de passe afin que les deux
s'en servent comme mot de passe "SRP"?
--
Kevin
Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Je vais lire, merci.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"? -- Kevin
Erwan David
Kevin Denis écrivait :
Le 17-01-2011, Thomas Pornin a écrit :
Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Je vais lire, merci.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"?
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant de rejouer la session d'authentification et d'accéder au serveur.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Kevin Denis <kevin@nowhere.invalid> écrivait :
Le 17-01-2011, Thomas Pornin <pornin@bolet.org> a écrit :
Néanmoins, un faux serveur ou un faux client
n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
SRP est intégré dans SSL/TLS, cf RFC 5054 :
http://tools.ietf.org/html/rfc5054
(on attend que les browsers Web veuillent bien l'implémenter).
Je vais lire, merci.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
Trivialement, rien n'empêche le serveur de fournir le salt au client,
qui va s'en servir pour hacher son mot de passe afin que les deux
s'en servent comme mot de passe "SRP"?
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant
de rejouer la session d'authentification et d'accéder au serveur.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
SRP est intégré dans SSL/TLS, cf RFC 5054 : http://tools.ietf.org/html/rfc5054 (on attend que les browsers Web veuillent bien l'implémenter).
Je vais lire, merci.
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour que ça tombe sur les mêmes mots de passe que les mots de passe Unix pourrait être compliqué.
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"?
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant de rejouer la session d'authentification et d'accéder au serveur.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Kevin Denis
Le 17-01-2011, Erwan David a écrit :
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"?
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant de rejouer la session d'authentification et d'accéder au serveur.
Apparemment, non, puisque SRP est censé empêcher cela.
Si je lis bien ce que dis Thomas Pornin, c'est que SRP a besoin de connaitre le mot de passe, à tout le moins le haché SRP du mot de passe.
Comme UNIX stocke ses mots de passe à sa manière, SRP est difficilement compatible avec celui-ci.
Qu'a cela ne tienne, utilisons le haché UNIX comme mot de passe qui va servir à l'authent SRP, après tout. SRP ayant besoin qu'un serveur et qu'un client connaissent un mot de passe, qu'est ce qui empêche d'utiliser le haché unix? Le serveur connait le haché UNIX, c'est le deuxième champ de /etc/shadow. Le client ne connait pas son haché, mais connaît son mot de passe, ce qui lui permet de calculer le haché, pour peu qu'on lui fournisse le salt.
Et donc un attaquant verra peut-être passer un salt, mais c'est à peu près tout. -- Kevin
Le 17-01-2011, Erwan David <erwan@rail.eu.org> a écrit :
Trivialement, rien n'empêche le serveur de fournir le salt au client,
qui va s'en servir pour hacher son mot de passe afin que les deux
s'en servent comme mot de passe "SRP"?
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant
de rejouer la session d'authentification et d'accéder au serveur.
Apparemment, non, puisque SRP est censé empêcher cela.
Si je lis bien ce que dis Thomas Pornin, c'est que SRP a besoin de
connaitre le mot de passe, à tout le moins le haché SRP du mot de passe.
Comme UNIX stocke ses mots de passe à sa manière, SRP est difficilement
compatible avec celui-ci.
Qu'a cela ne tienne, utilisons le haché UNIX comme mot de passe qui va
servir à l'authent SRP, après tout. SRP ayant besoin qu'un serveur et
qu'un client connaissent un mot de passe, qu'est ce qui empêche
d'utiliser le haché unix? Le serveur connait le haché UNIX, c'est le
deuxième champ de /etc/shadow. Le client ne connait pas son
haché, mais connaît son mot de passe, ce qui lui permet de calculer
le haché, pour peu qu'on lui fournisse le salt.
Et donc un attaquant verra peut-être passer un salt, mais c'est à peu
près tout.
--
Kevin
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"?
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant de rejouer la session d'authentification et d'accéder au serveur.
Apparemment, non, puisque SRP est censé empêcher cela.
Si je lis bien ce que dis Thomas Pornin, c'est que SRP a besoin de connaitre le mot de passe, à tout le moins le haché SRP du mot de passe.
Comme UNIX stocke ses mots de passe à sa manière, SRP est difficilement compatible avec celui-ci.
Qu'a cela ne tienne, utilisons le haché UNIX comme mot de passe qui va servir à l'authent SRP, après tout. SRP ayant besoin qu'un serveur et qu'un client connaissent un mot de passe, qu'est ce qui empêche d'utiliser le haché unix? Le serveur connait le haché UNIX, c'est le deuxième champ de /etc/shadow. Le client ne connait pas son haché, mais connaît son mot de passe, ce qui lui permet de calculer le haché, pour peu qu'on lui fournisse le salt.
Et donc un attaquant verra peut-être passer un salt, mais c'est à peu près tout. -- Kevin
Thomas Pornin
According to Kevin Denis :
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"?
C'est théoriquement possible. Échanger la salt "en clair" n'est pas un problème de sécurité ; ensuite, c'est le mot de passe Unix haché qui sert lui-même de mot de passe pour SRP.
Suivant le protocole, ça peut nécessiter des messages supplémentaires, donc de la latence. Le client doit d'abord dire qui il est ; le serveur peut alors lui renvoyer sa salt, et là seulement le client peut fabriquer son message.
Sinon, comme le fait remarquer Erwan, ça va mal fonctionner avec des choses comme Kerberos ou LDAP. Sur un Unix avec du LDAP (du moins tel que je l'ai pratiqué), le serveur LDAP connaît le mot de passe et exige sa présentation pour authentifier l'utilisateur -- le serveur, lui, ne peut pas obtenir le mot de passe ou même un haché du mot de passe de façon préalable... Bref, si le concept PAKE est intéressant d'un point de vue sécurité, il ne s'intègre pas très bien dans un environnement Unixoïde qui a déjà son propre écosystème de gestion de mots de passe.
--Thomas Pornin
According to Kevin Denis <kevin@alinto.comNOSPAM>:
Trivialement, rien n'empêche le serveur de fournir le salt au client,
qui va s'en servir pour hacher son mot de passe afin que les deux
s'en servent comme mot de passe "SRP"?
C'est théoriquement possible. Échanger la salt "en clair" n'est pas
un problème de sécurité ; ensuite, c'est le mot de passe Unix haché
qui sert lui-même de mot de passe pour SRP.
Suivant le protocole, ça peut nécessiter des messages supplémentaires,
donc de la latence. Le client doit d'abord dire qui il est ; le
serveur peut alors lui renvoyer sa salt, et là seulement le client
peut fabriquer son message.
Sinon, comme le fait remarquer Erwan, ça va mal fonctionner avec des
choses comme Kerberos ou LDAP. Sur un Unix avec du LDAP (du moins tel
que je l'ai pratiqué), le serveur LDAP connaît le mot de passe et exige
sa présentation pour authentifier l'utilisateur -- le serveur, lui, ne
peut pas obtenir le mot de passe ou même un haché du mot de passe de
façon préalable... Bref, si le concept PAKE est intéressant d'un point
de vue sécurité, il ne s'intègre pas très bien dans un environnement
Unixoïde qui a déjà son propre écosystème de gestion de mots de passe.
Trivialement, rien n'empêche le serveur de fournir le salt au client, qui va s'en servir pour hacher son mot de passe afin que les deux s'en servent comme mot de passe "SRP"?
C'est théoriquement possible. Échanger la salt "en clair" n'est pas un problème de sécurité ; ensuite, c'est le mot de passe Unix haché qui sert lui-même de mot de passe pour SRP.
Suivant le protocole, ça peut nécessiter des messages supplémentaires, donc de la latence. Le client doit d'abord dire qui il est ; le serveur peut alors lui renvoyer sa salt, et là seulement le client peut fabriquer son message.
Sinon, comme le fait remarquer Erwan, ça va mal fonctionner avec des choses comme Kerberos ou LDAP. Sur un Unix avec du LDAP (du moins tel que je l'ai pratiqué), le serveur LDAP connaît le mot de passe et exige sa présentation pour authentifier l'utilisateur -- le serveur, lui, ne peut pas obtenir le mot de passe ou même un haché du mot de passe de façon préalable... Bref, si le concept PAKE est intéressant d'un point de vue sécurité, il ne s'intègre pas très bien dans un environnement Unixoïde qui a déjà son propre écosystème de gestion de mots de passe.
