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.
On Sat, 26 Feb 2005 16:28:13 +0000, Nicolas George wrote:
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.
C'est absolument faux. Il n'y a aucune obligation d'avoir le mot de passe en clair ni aucune information qui permette de le retrouver pour mettre au point une méthode d'authentification par challenge. Il suffit d'utiliser un dérivé du mot de passe de qualité cryptographique, c.a.d qui garantisse que deux mots de passes ne donnent pas le même résultat et qu'il est impossible de remonter au mot de passe à partir du résultat. C'est exactement ce que sont les hash de type md5 ou sha ou autres qui servent _effectivement_ pour stocker les mots de passe.
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).
Je n'ai jamais prétendu que le "shadow password" permettait d'usurper l'identité d'un utilisateur. J'ai dit qu'ils permettent de mettre en place une authentification par challenge. C'est tellement vrai que c'est ce qui sert en réalité: le challenge n'est pas résolu par la combinaison (mot de passe + challenge alléatoire) mais par une combinaison de (hash du mot de passe + challenge alléatoire). Si le hash employé est de qualité cryptographique, le résultat est strictement le même au niveau de la qualité de l'authentification et le serveur n'a jamais besoin de connaitre le mot de passe, seulement son hash. Quand aux différences de stockage des mots de passes (utilisation d'un sel de hachage, différentes méthodes de hashage), c'est vrai qu'elles existent, c'est pourquoi lorsqu'il y a authentification par challenge (je parle de vrai authentification sécurisée, pas de bidouillage), le serveur fournit avec le challenge le sel et la méthode à utiliser pour hasher le mot de passe. Il y a parfois aussi négociation de la méthode employée pour hasher le challenge avec le hash du mot de passe. Si ce que tu disais était vrai (mots de passes stockés en clair), ces méthodes d'authentifications seraient inutilisables car bien trop dangereuses (il suffit de hacker 1 machine pour avoir tous les mots de passes...). Hors, les authentifications par challenges sont très largement répandues, justement parce que leur niveau de sécurité est très satisfaisant en l'état actuel de la technique du moment que les fonctions de hashage sont fiables (en termes cryptographiques, toujours).
En passant, trouver une collision dans une fonction de hashage n'est pas difficile, c'est même une évidence. Ce qui rends une fonction de hashage sure, c'est l'impossibilité de prédire une collision autrement que par la force brute, c'est une nuance de très grande importance.
On Sat, 26 Feb 2005 16:28:13 +0000, Nicolas George wrote:
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.
C'est absolument faux. Il n'y a aucune obligation d'avoir le mot de passe
en clair ni aucune information qui permette de le retrouver pour mettre au
point une méthode d'authentification par challenge. Il suffit d'utiliser
un dérivé du mot de passe de qualité cryptographique, c.a.d qui
garantisse que deux mots de passes ne donnent pas le même résultat et
qu'il est impossible de remonter au mot de passe à partir du résultat.
C'est exactement ce que sont les hash de type md5 ou sha ou autres qui
servent _effectivement_ pour stocker les mots de passe.
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).
Je n'ai jamais prétendu que le "shadow password" permettait d'usurper
l'identité d'un utilisateur. J'ai dit qu'ils permettent de mettre en
place une authentification par challenge. C'est tellement vrai que c'est
ce qui sert en réalité: le challenge n'est pas résolu par la
combinaison (mot de passe + challenge alléatoire) mais par une
combinaison de (hash du mot de passe + challenge alléatoire). Si le hash
employé est de qualité cryptographique, le résultat est strictement le
même au niveau de la qualité de l'authentification et le serveur n'a
jamais besoin de connaitre le mot de passe, seulement son hash.
Quand aux différences de stockage des mots de passes (utilisation d'un
sel de hachage, différentes méthodes de hashage), c'est vrai qu'elles
existent, c'est pourquoi lorsqu'il y a authentification par challenge (je
parle de vrai authentification sécurisée, pas de bidouillage), le
serveur fournit avec le challenge le sel et la méthode à utiliser pour
hasher le mot de passe. Il y a parfois aussi négociation de la méthode
employée pour hasher le challenge avec le hash du mot de passe.
Si ce que tu disais était vrai (mots de passes stockés en
clair), ces méthodes d'authentifications seraient inutilisables car bien
trop dangereuses (il suffit de hacker 1 machine pour avoir tous les mots
de passes...). Hors, les authentifications par challenges sont très
largement répandues, justement parce que leur niveau de sécurité est
très satisfaisant en l'état actuel de la technique du moment que les
fonctions de hashage sont fiables (en termes cryptographiques, toujours).
En passant, trouver une collision dans une fonction de hashage n'est pas
difficile, c'est même une évidence. Ce qui rends une fonction de hashage
sure, c'est l'impossibilité de prédire une collision autrement que
par la force brute, c'est une nuance de très grande importance.
On Sat, 26 Feb 2005 16:28:13 +0000, Nicolas George wrote:
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.
C'est absolument faux. Il n'y a aucune obligation d'avoir le mot de passe en clair ni aucune information qui permette de le retrouver pour mettre au point une méthode d'authentification par challenge. Il suffit d'utiliser un dérivé du mot de passe de qualité cryptographique, c.a.d qui garantisse que deux mots de passes ne donnent pas le même résultat et qu'il est impossible de remonter au mot de passe à partir du résultat. C'est exactement ce que sont les hash de type md5 ou sha ou autres qui servent _effectivement_ pour stocker les mots de passe.
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).
Je n'ai jamais prétendu que le "shadow password" permettait d'usurper l'identité d'un utilisateur. J'ai dit qu'ils permettent de mettre en place une authentification par challenge. C'est tellement vrai que c'est ce qui sert en réalité: le challenge n'est pas résolu par la combinaison (mot de passe + challenge alléatoire) mais par une combinaison de (hash du mot de passe + challenge alléatoire). Si le hash employé est de qualité cryptographique, le résultat est strictement le même au niveau de la qualité de l'authentification et le serveur n'a jamais besoin de connaitre le mot de passe, seulement son hash. Quand aux différences de stockage des mots de passes (utilisation d'un sel de hachage, différentes méthodes de hashage), c'est vrai qu'elles existent, c'est pourquoi lorsqu'il y a authentification par challenge (je parle de vrai authentification sécurisée, pas de bidouillage), le serveur fournit avec le challenge le sel et la méthode à utiliser pour hasher le mot de passe. Il y a parfois aussi négociation de la méthode employée pour hasher le challenge avec le hash du mot de passe. Si ce que tu disais était vrai (mots de passes stockés en clair), ces méthodes d'authentifications seraient inutilisables car bien trop dangereuses (il suffit de hacker 1 machine pour avoir tous les mots de passes...). Hors, les authentifications par challenges sont très largement répandues, justement parce que leur niveau de sécurité est très satisfaisant en l'état actuel de la technique du moment que les fonctions de hashage sont fiables (en termes cryptographiques, toujours).
En passant, trouver une collision dans une fonction de hashage n'est pas difficile, c'est même une évidence. Ce qui rends une fonction de hashage sure, c'est l'impossibilité de prédire une collision autrement que par la force brute, c'est une nuance de très grande importance.
Nicolas George
l'indien wrote in message :
même au niveau de la qualité de l'authentification et le serveur n'a jamais besoin de connaitre le mot de passe, seulement son hash.
Précisément. Mais ce que je dis, et que tu n'as pas compris, c'est que le client a également besoin de « seulement son hash » pour s'authentifier.
En d'autres termes, si tu me donnes la ligne correspondant à ton compte dans /etc/shadow, je ne peux rien en faire à moins de trouver une collision (ce qui, nous sommes d'accord, ne demande rien de plus complexe que quelques années ou siècles de force brute). Mais si cette ligne est utilisée dans un schéma challenge-réponse, alors j'ai tout ce qu'il me faut pour m'authentifier. Je n'ai pas la possibilité de retrouver le mot de passe, mais je n'ai pas besoin du mot de passe.
Dit autrement : dans un schéma challenge-réponse, le mot de passe lui-même n'est qu'un moyen mnémotechnique pour mémoriser le « vrai » mot de passe, qui est le hash qu'en a le serveur.
Pour formaliser ça, on peut noter ça comme ça : le serveur envoit challenge, le client répond par
réponse = F(challenge, mot-de-passe)
et le serveur autorise l'accès si
réponse == G(challenge, certificat-du-client)
où certificat-du-client = hash(mot-de-passe) est ce que le serveur a dans ses bases de données, et où
F(c, mdp) = G(c, hash(mdp))
est une décomposition simple des fonctions utilisées.
Maintenant, si je peux avoir accès en lecture aux bases de données du serveur, je connais certificat-du-client, et je peux alors m'authentifier auprès du serveur, non pas en utilisant la fonction F comme un client normal, mais en utilisant la fonction G directement.
l'indien wrote in message <pan.2005.02.26.18.09.24.156307@magic.fr>:
même au niveau de la qualité de l'authentification et le serveur n'a
jamais besoin de connaitre le mot de passe, seulement son hash.
Précisément. Mais ce que je dis, et que tu n'as pas compris, c'est que le
client a également besoin de « seulement son hash » pour s'authentifier.
En d'autres termes, si tu me donnes la ligne correspondant à ton compte dans
/etc/shadow, je ne peux rien en faire à moins de trouver une collision (ce
qui, nous sommes d'accord, ne demande rien de plus complexe que quelques
années ou siècles de force brute). Mais si cette ligne est utilisée dans un
schéma challenge-réponse, alors j'ai tout ce qu'il me faut pour
m'authentifier. Je n'ai pas la possibilité de retrouver le mot de passe,
mais je n'ai pas besoin du mot de passe.
Dit autrement : dans un schéma challenge-réponse, le mot de passe lui-même
n'est qu'un moyen mnémotechnique pour mémoriser le « vrai » mot de passe,
qui est le hash qu'en a le serveur.
Pour formaliser ça, on peut noter ça comme ça : le serveur envoit challenge,
le client répond par
réponse = F(challenge, mot-de-passe)
et le serveur autorise l'accès si
réponse == G(challenge, certificat-du-client)
où certificat-du-client = hash(mot-de-passe) est ce que le serveur a dans
ses bases de données, et où
F(c, mdp) = G(c, hash(mdp))
est une décomposition simple des fonctions utilisées.
Maintenant, si je peux avoir accès en lecture aux bases de données du
serveur, je connais certificat-du-client, et je peux alors m'authentifier
auprès du serveur, non pas en utilisant la fonction F comme un client
normal, mais en utilisant la fonction G directement.
même au niveau de la qualité de l'authentification et le serveur n'a jamais besoin de connaitre le mot de passe, seulement son hash.
Précisément. Mais ce que je dis, et que tu n'as pas compris, c'est que le client a également besoin de « seulement son hash » pour s'authentifier.
En d'autres termes, si tu me donnes la ligne correspondant à ton compte dans /etc/shadow, je ne peux rien en faire à moins de trouver une collision (ce qui, nous sommes d'accord, ne demande rien de plus complexe que quelques années ou siècles de force brute). Mais si cette ligne est utilisée dans un schéma challenge-réponse, alors j'ai tout ce qu'il me faut pour m'authentifier. Je n'ai pas la possibilité de retrouver le mot de passe, mais je n'ai pas besoin du mot de passe.
Dit autrement : dans un schéma challenge-réponse, le mot de passe lui-même n'est qu'un moyen mnémotechnique pour mémoriser le « vrai » mot de passe, qui est le hash qu'en a le serveur.
Pour formaliser ça, on peut noter ça comme ça : le serveur envoit challenge, le client répond par
réponse = F(challenge, mot-de-passe)
et le serveur autorise l'accès si
réponse == G(challenge, certificat-du-client)
où certificat-du-client = hash(mot-de-passe) est ce que le serveur a dans ses bases de données, et où
F(c, mdp) = G(c, hash(mdp))
est une décomposition simple des fonctions utilisées.
Maintenant, si je peux avoir accès en lecture aux bases de données du serveur, je connais certificat-du-client, et je peux alors m'authentifier auprès du serveur, non pas en utilisant la fonction F comme un client normal, mais en utilisant la fonction G directement.
l'indien
On Sat, 26 Feb 2005 18:40:46 +0000, Nicolas George wrote:
l'indien wrote in message :
même au niveau de la qualité de l'authentification et le serveur n'a jamais besoin de connaitre le mot de passe, seulement son hash.
Précisément. Mais ce que je dis, et que tu n'as pas compris, c'est que le client a également besoin de « seulement son hash » pour s'authentifier.
Pour formaliser ça, on peut noter ça comme ça : le serveur envoit challenge, le client répond par
réponse = F(challenge, mot-de-passe)
et le serveur autorise l'accès si
réponse == G(challenge, certificat-du-client)
où certificat-du-client = hash(mot-de-passe) est ce que le serveur a dans ses bases de données, et où
F(c, mdp) = G(c, hash(mdp))
est une décomposition simple des fonctions utilisées.
OK, je n'avais effectivement pas compris ce que tu voulais dire. Tu as raison.
On Sat, 26 Feb 2005 18:40:46 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.02.26.18.09.24.156307@magic.fr>:
même au niveau de la qualité de l'authentification et le serveur n'a
jamais besoin de connaitre le mot de passe, seulement son hash.
Précisément. Mais ce que je dis, et que tu n'as pas compris, c'est que le
client a également besoin de « seulement son hash » pour s'authentifier.
Pour formaliser ça, on peut noter ça comme ça : le serveur envoit challenge,
le client répond par
réponse = F(challenge, mot-de-passe)
et le serveur autorise l'accès si
réponse == G(challenge, certificat-du-client)
où certificat-du-client = hash(mot-de-passe) est ce que le serveur a dans
ses bases de données, et où
F(c, mdp) = G(c, hash(mdp))
est une décomposition simple des fonctions utilisées.
OK, je n'avais effectivement pas compris ce que tu voulais dire.
Tu as raison.
