In article <190120162052052280%, Jean-Pierre Kuypers wrote:
In article (Dans l'article) , marioski wrote (écrivait) :
> A quoi cela sert de crypter ses mots de passe
Comment fait-on pour crypter des mots de passe, i.e. les chiffrer sans connaître la clé de chiffrement ?
je perçois l'amorce d'un dialogue de sourds... :)
patpro
-- À vendre : http://www.leboncoin.fr/informatique/821220894.htm http://www.leboncoin.fr/informatique/821221994.htm
MAIxxx
Le 19/01/2016 19:12, marioski a écrit :
bonjour,
A quoi cela sert de crypter ses mots de passe sauf sinon de protéger leur confidentialité?
N'y a-t-il pas moyen,un site,un outil qui changerait automatiquement et dynamiquement un mot de passe?
merci de votre aide
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Le serveur pose la question "mot de passe = ?" peut être remplacé par le serveur envoie une donnée aléatoire de connexion X Le client répond alors avec une donnée D=f(X). c'est une RFC existante si je me souviens bien mais limitée à une fonction spécifiée fixe.
La fonction f() peut aussi inclure une parie aléatoire Y (un masque) et être de la forme (g(X) & Y ) |( Z & !Y ) les bits mis à 0 par Y étant modifiés par la variable aléatoire Z générée par le client.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Noter que la donnée X peut aussi contenir une donnée X' extractible par le client et identifiant le serveur pour un client répertorié.
La vérification par le serveur ne concernera que les bits non masqués. Le décryptage est rendu très difficile, le "mot de passe" transmis étant d'apparence aléatoire. La mise en oeuvre est très simple mais suppose que les "questions" ne soient pas répétées avec la même donnée X par un serveur fake.
Le 19/01/2016 19:12, marioski a écrit :
bonjour,
A quoi cela sert de crypter ses mots de passe sauf sinon de protéger leur confidentialité?
N'y a-t-il pas moyen,un site,un outil qui changerait automatiquement et dynamiquement un mot de passe?
merci de votre aide
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Le serveur pose la question "mot de passe = ?" peut être remplacé par
le serveur envoie une donnée aléatoire de connexion X
Le client répond alors avec une donnée D=f(X). c'est une RFC existante
si je me souviens bien mais limitée à une fonction spécifiée fixe.
La fonction f() peut aussi inclure une parie aléatoire Y (un masque) et
être de la forme
(g(X) & Y ) |( Z & !Y ) les bits mis à 0 par Y étant modifiés par
la variable aléatoire Z générée par le client.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Noter que la donnée X peut aussi contenir une donnée X' extractible par
le client et identifiant le serveur pour un client répertorié.
La vérification par le serveur ne concernera que les bits non masqués.
Le décryptage est rendu très difficile, le "mot de passe" transmis
étant d'apparence aléatoire. La mise en oeuvre est très simple mais
suppose que les "questions" ne soient pas répétées avec la même donnée X
par un serveur fake.
A quoi cela sert de crypter ses mots de passe sauf sinon de protéger leur confidentialité?
N'y a-t-il pas moyen,un site,un outil qui changerait automatiquement et dynamiquement un mot de passe?
merci de votre aide
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Le serveur pose la question "mot de passe = ?" peut être remplacé par le serveur envoie une donnée aléatoire de connexion X Le client répond alors avec une donnée D=f(X). c'est une RFC existante si je me souviens bien mais limitée à une fonction spécifiée fixe.
La fonction f() peut aussi inclure une parie aléatoire Y (un masque) et être de la forme (g(X) & Y ) |( Z & !Y ) les bits mis à 0 par Y étant modifiés par la variable aléatoire Z générée par le client.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Noter que la donnée X peut aussi contenir une donnée X' extractible par le client et identifiant le serveur pour un client répertorié.
La vérification par le serveur ne concernera que les bits non masqués. Le décryptage est rendu très difficile, le "mot de passe" transmis étant d'apparence aléatoire. La mise en oeuvre est très simple mais suppose que les "questions" ne soient pas répétées avec la même donnée X par un serveur fake.
Nicolas George
MAIxxx , dans le message <n7mgbh$cb5$, a écrit :
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Tous les experts en sécurité s'accordent à dire que c'est une très mauvaise idée. L'algorithme doit être bien connu pour être bien étudié et ne pas avoir de failles, et s'il était compromis, il faudrait refaire l'étude.
Donc la bonne pratique, c'est un algorithme standard bien étudié et une clef secrète générée de manière aussi libre que possible.
Le serveur pose la question "mot de passe = ?" peut être remplacé par le serveur envoie une donnée aléatoire de connexion X Le client répond alors avec une donnée D=f(X). c'est une RFC existante si je me souviens bien mais limitée à une fonction spécifiée fixe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui, chaque protocole utilise une fonction fixe (ou une petite liste de fonctions autorisées), pour la raison ci-dessus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que la donnée de la valeur pour différentes entrées ne permette pas facilement de déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, un espion qui a observé plusieurs échanges peut s'en servir pour s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans son garage n'ont pas cette propriété, elles risquent même d'assez facilement laisser reconstituer la clef elle-même.
MAIxxx , dans le message <n7mgbh$cb5$1@dont-email.me>, a écrit :
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Tous les experts en sécurité s'accordent à dire que c'est une très mauvaise
idée. L'algorithme doit être bien connu pour être bien étudié et ne pas
avoir de failles, et s'il était compromis, il faudrait refaire l'étude.
Donc la bonne pratique, c'est un algorithme standard bien étudié et une clef
secrète générée de manière aussi libre que possible.
Le serveur pose la question "mot de passe = ?" peut être remplacé par
le serveur envoie une donnée aléatoire de connexion X
Le client répond alors avec une donnée D=f(X). c'est une RFC existante
si je me souviens bien mais limitée à une fonction spécifiée fixe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui,
chaque protocole utilise une fonction fixe (ou une petite liste de fonctions
autorisées), pour la raison ci-dessus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que la
donnée de la valeur pour différentes entrées ne permette pas facilement de
déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, un
espion qui a observé plusieurs échanges peut s'en servir pour
s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans son
garage n'ont pas cette propriété, elles risquent même d'assez facilement
laisser reconstituer la clef elle-même.
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Tous les experts en sécurité s'accordent à dire que c'est une très mauvaise idée. L'algorithme doit être bien connu pour être bien étudié et ne pas avoir de failles, et s'il était compromis, il faudrait refaire l'étude.
Donc la bonne pratique, c'est un algorithme standard bien étudié et une clef secrète générée de manière aussi libre que possible.
Le serveur pose la question "mot de passe = ?" peut être remplacé par le serveur envoie une donnée aléatoire de connexion X Le client répond alors avec une donnée D=f(X). c'est une RFC existante si je me souviens bien mais limitée à une fonction spécifiée fixe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui, chaque protocole utilise une fonction fixe (ou une petite liste de fonctions autorisées), pour la raison ci-dessus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que la donnée de la valeur pour différentes entrées ne permette pas facilement de déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, un espion qui a observé plusieurs échanges peut s'en servir pour s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans son garage n'ont pas cette propriété, elles risquent même d'assez facilement laisser reconstituer la clef elle-même.
marioski
Le mercredi 20 janvier 2016 16:18:01 UTC+1, Nicolas George a écrit :
MAIxxx , dans le message <n7mgbh$cb5$, a écrit : > J'avais une solution simple : transformer le "mot de passe" en algorit hme.
Tous les experts en sécurité s'accordent à dire que c'est une trè s mauvaise idée. L'algorithme doit être bien connu pour être bien étudié e t ne pas avoir de failles, et s'il était compromis, il faudrait refaire l'étud e.
Donc la bonne pratique, c'est un algorithme standard bien étudié et u ne clef secrète générée de manière aussi libre que possible.
> Le serveur pose la question "mot de passe = ?" peut être remplacé par > le serveur envoie une donnée aléatoire de connexion X > Le client répond alors avec une donnée D=f(X). c'est une RFC exis tante > si je me souviens bien mais limitée à une fonction spécifiée fi xe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui, chaque protocole utilise une fonction fixe (ou une petite liste de foncti ons autorisées), pour la raison ci-dessus.
> La fonction f peut être arithmétique quelconque, par exemple un pol ynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que l a donnée de la valeur pour différentes entrées ne permette pas facile ment de déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, u n espion qui a observé plusieurs échanges peut s'en servir pour s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans so n garage n'ont pas cette propriété, elles risquent même d'assez facil ement laisser reconstituer la clef elle-même.
je pensais qu'il existe ou existera un serveur intégré à chaque navig ateur dans lequel l'intrusion serait impossible et qui retiendrait tous les mots de passe enregistrés et auto-changeables dynamiquement à une fr équence choisie,de telle manière qu'à chaque moment où l'internaute se connecte à un site avec son mot de passe(qui aura changé plusieurs fois auparavant et automatiquement),il l'utilisera.Si bien qu'aucun pirate ne pourrait rentrer dans un site puisqu'il n'aura jamais le temps de récu pérer le bon mot de passe qui sera changé automatiquement,rapidement et à pludieurs reprises! Cette technologie existe-t-elle déjà ou sera-t-elle un jour envisageabl e?
Le mercredi 20 janvier 2016 16:18:01 UTC+1, Nicolas George a écrit :
MAIxxx , dans le message <n7mgbh$cb5$1@dont-email.me>, a écrit :
> J'avais une solution simple : transformer le "mot de passe" en algorit hme.
Tous les experts en sécurité s'accordent à dire que c'est une trè s mauvaise
idée. L'algorithme doit être bien connu pour être bien étudié e t ne pas
avoir de failles, et s'il était compromis, il faudrait refaire l'étud e.
Donc la bonne pratique, c'est un algorithme standard bien étudié et u ne clef
secrète générée de manière aussi libre que possible.
> Le serveur pose la question "mot de passe = ?" peut être remplacé par
> le serveur envoie une donnée aléatoire de connexion X
> Le client répond alors avec une donnée D=f(X). c'est une RFC exis tante
> si je me souviens bien mais limitée à une fonction spécifiée fi xe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui,
chaque protocole utilise une fonction fixe (ou une petite liste de foncti ons
autorisées), pour la raison ci-dessus.
> La fonction f peut être arithmétique quelconque, par exemple un pol ynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que l a
donnée de la valeur pour différentes entrées ne permette pas facile ment de
déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, u n
espion qui a observé plusieurs échanges peut s'en servir pour
s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans so n
garage n'ont pas cette propriété, elles risquent même d'assez facil ement
laisser reconstituer la clef elle-même.
je pensais qu'il existe ou existera un serveur intégré à chaque navig ateur dans lequel l'intrusion serait impossible et qui retiendrait tous les mots de passe enregistrés et auto-changeables dynamiquement à une fr équence choisie,de telle manière qu'à chaque moment où l'internaute se connecte à un site avec son mot de passe(qui aura changé plusieurs fois auparavant et automatiquement),il l'utilisera.Si bien qu'aucun pirate ne pourrait rentrer dans un site puisqu'il n'aura jamais le temps de récu pérer le bon mot de passe qui sera changé automatiquement,rapidement et à pludieurs reprises!
Cette technologie existe-t-elle déjà ou sera-t-elle un jour envisageabl e?
Le mercredi 20 janvier 2016 16:18:01 UTC+1, Nicolas George a écrit :
MAIxxx , dans le message <n7mgbh$cb5$, a écrit : > J'avais une solution simple : transformer le "mot de passe" en algorit hme.
Tous les experts en sécurité s'accordent à dire que c'est une trè s mauvaise idée. L'algorithme doit être bien connu pour être bien étudié e t ne pas avoir de failles, et s'il était compromis, il faudrait refaire l'étud e.
Donc la bonne pratique, c'est un algorithme standard bien étudié et u ne clef secrète générée de manière aussi libre que possible.
> Le serveur pose la question "mot de passe = ?" peut être remplacé par > le serveur envoie une donnée aléatoire de connexion X > Le client répond alors avec une donnée D=f(X). c'est une RFC exis tante > si je me souviens bien mais limitée à une fonction spécifiée fi xe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui, chaque protocole utilise une fonction fixe (ou une petite liste de foncti ons autorisées), pour la raison ci-dessus.
> La fonction f peut être arithmétique quelconque, par exemple un pol ynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que l a donnée de la valeur pour différentes entrées ne permette pas facile ment de déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, u n espion qui a observé plusieurs échanges peut s'en servir pour s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans so n garage n'ont pas cette propriété, elles risquent même d'assez facil ement laisser reconstituer la clef elle-même.
je pensais qu'il existe ou existera un serveur intégré à chaque navig ateur dans lequel l'intrusion serait impossible et qui retiendrait tous les mots de passe enregistrés et auto-changeables dynamiquement à une fr équence choisie,de telle manière qu'à chaque moment où l'internaute se connecte à un site avec son mot de passe(qui aura changé plusieurs fois auparavant et automatiquement),il l'utilisera.Si bien qu'aucun pirate ne pourrait rentrer dans un site puisqu'il n'aura jamais le temps de récu pérer le bon mot de passe qui sera changé automatiquement,rapidement et à pludieurs reprises! Cette technologie existe-t-elle déjà ou sera-t-elle un jour envisageabl e?
MAIxxx
Le 20/01/2016 16:18, Nicolas George a écrit :
MAIxxx , dans le message <n7mgbh$cb5$, a écrit :
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Tous les experts en sécurité s'accordent à dire que c'est une très mauvaise idée. L'algorithme doit être bien connu pour être bien étudié et ne pas avoir de failles, et s'il était compromis, il faudrait refaire l'étude.
Donc la bonne pratique, c'est un algorithme standard bien étudié et une clef secrète générée de manière aussi libre que possible.
Le serveur pose la question "mot de passe = ?" peut être remplacé par le serveur envoie une donnée aléatoire de connexion X Le client répond alors avec une donnée D=f(X). c'est une RFC existante si je me souviens bien mais limitée à une fonction spécifiée fixe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui, chaque protocole utilise une fonction fixe (ou une petite liste de fonctions autorisées), pour la raison ci-dessus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que la donnée de la valeur pour différentes entrées ne permette pas facilement de déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, un espion qui a observé plusieurs échanges peut s'en servir pour s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans son garage n'ont pas cette propriété, elles risquent même d'assez facilement laisser reconstituer la clef elle-même.
Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été inventé par un dilettante dans son garage.
Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à vos yeux (et c'est vrai, on sait la casser), l'idée d'introduire de l'aléatoire dans la réponse au "challenge" est assez facile à réaliser, masquant toute régularité dans la réponse.
Noter que la requête "challenge" peut contenir une identification du serveur de la même façon, une "signature" de la requête.
Noter enfin que EAP (RFC 3748,6247,7057..) Extensible Authentication protocol
contient à boire et à manger en matière d'identification.
Maintenant, si on veut faire du PAP avec un mot de passe qui change chaque fois, il faut que le serveur et le client partagent un "secret" qui leur permettent de s'entendre, à savoir le passage d'un mot de passe à un autre, avec un côté aléatoire, vu des tiers. Evidemment si la méthode "mastermind" permet de retrouver comment on fait, ça n'est pas sécurisé. On peut bien sûr combiner avec CHAP plutôt que PAP.
cdt
Le 20/01/2016 16:18, Nicolas George a écrit :
MAIxxx , dans le message <n7mgbh$cb5$1@dont-email.me>, a écrit :
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Tous les experts en sécurité s'accordent à dire que c'est une très mauvaise
idée. L'algorithme doit être bien connu pour être bien étudié et ne pas
avoir de failles, et s'il était compromis, il faudrait refaire l'étude.
Donc la bonne pratique, c'est un algorithme standard bien étudié et une clef
secrète générée de manière aussi libre que possible.
Le serveur pose la question "mot de passe = ?" peut être remplacé par
le serveur envoie une donnée aléatoire de connexion X
Le client répond alors avec une donnée D=f(X). c'est une RFC existante
si je me souviens bien mais limitée à une fonction spécifiée fixe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui,
chaque protocole utilise une fonction fixe (ou une petite liste de fonctions
autorisées), pour la raison ci-dessus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que la
donnée de la valeur pour différentes entrées ne permette pas facilement de
déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, un
espion qui a observé plusieurs échanges peut s'en servir pour
s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans son
garage n'ont pas cette propriété, elles risquent même d'assez facilement
laisser reconstituer la clef elle-même.
Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été
inventé par un dilettante dans son garage.
Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à vos
yeux (et c'est vrai, on sait la casser), l'idée d'introduire de
l'aléatoire dans la réponse au "challenge" est assez facile à réaliser,
masquant toute régularité dans la réponse.
Noter que la requête "challenge" peut contenir une identification du
serveur de la même façon, une "signature" de la requête.
Noter enfin que EAP (RFC 3748,6247,7057..) Extensible Authentication
protocol
contient à boire et à manger en matière d'identification.
Maintenant, si on veut faire du PAP avec un mot de passe qui change
chaque fois, il faut que le serveur et le client partagent un "secret"
qui leur permettent de s'entendre, à savoir le passage d'un mot de passe
à un autre, avec un côté aléatoire, vu des tiers. Evidemment si la
méthode "mastermind" permet de retrouver comment on fait, ça n'est pas
sécurisé. On peut bien sûr combiner avec CHAP plutôt que PAP.
J'avais une solution simple : transformer le "mot de passe" en algorithme.
Tous les experts en sécurité s'accordent à dire que c'est une très mauvaise idée. L'algorithme doit être bien connu pour être bien étudié et ne pas avoir de failles, et s'il était compromis, il faudrait refaire l'étude.
Donc la bonne pratique, c'est un algorithme standard bien étudié et une clef secrète générée de manière aussi libre que possible.
Le serveur pose la question "mot de passe = ?" peut être remplacé par le serveur envoie une donnée aléatoire de connexion X Le client répond alors avec une donnée D=f(X). c'est une RFC existante si je me souviens bien mais limitée à une fonction spécifiée fixe.
C'est ce qu'on appelle authentification par challenge-réponse. Et oui, chaque protocole utilise une fonction fixe (ou une petite liste de fonctions autorisées), pour la raison ci-dessus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Non. Pour qu'une fonction soit utilisable dans ce contexte, il faut que la donnée de la valeur pour différentes entrées ne permette pas facilement de déterminer la valeur pour une autre entrée. Si ce n'est pas le cas, un espion qui a observé plusieurs échanges peut s'en servir pour s'authentifier.
La plupart des fonctions qu'un dilettante peut inventer tout seul dans son garage n'ont pas cette propriété, elles risquent même d'assez facilement laisser reconstituer la clef elle-même.
Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été inventé par un dilettante dans son garage.
Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à vos yeux (et c'est vrai, on sait la casser), l'idée d'introduire de l'aléatoire dans la réponse au "challenge" est assez facile à réaliser, masquant toute régularité dans la réponse.
Noter que la requête "challenge" peut contenir une identification du serveur de la même façon, une "signature" de la requête.
Noter enfin que EAP (RFC 3748,6247,7057..) Extensible Authentication protocol
contient à boire et à manger en matière d'identification.
Maintenant, si on veut faire du PAP avec un mot de passe qui change chaque fois, il faut que le serveur et le client partagent un "secret" qui leur permettent de s'entendre, à savoir le passage d'un mot de passe à un autre, avec un côté aléatoire, vu des tiers. Evidemment si la méthode "mastermind" permet de retrouver comment on fait, ça n'est pas sécurisé. On peut bien sûr combiner avec CHAP plutôt que PAP.
cdt
Nicolas George
MAIxxx , dans le message <n84v6o$h81$, a écrit :
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été inventé par un dilettante dans son garage.
En effet, mais CHAP n'utilise pas une fonction de hachage qui soit un polynôme.
Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à vos yeux
C'était une bonne fonction au départ (et pas faite par un dilettante dans son garage), ça ne l'est plus.
MAIxxx , dans le message <n84v6o$h81$1@dont-email.me>, a écrit :
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été
inventé par un dilettante dans son garage.
En effet, mais CHAP n'utilise pas une fonction de hachage qui soit un
polynôme.
Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à vos
yeux
C'était une bonne fonction au départ (et pas faite par un dilettante dans
son garage), ça ne l'est plus.
La fonction f peut être arithmétique quelconque, par exemple un polynôme.
Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été inventé par un dilettante dans son garage.
En effet, mais CHAP n'utilise pas une fonction de hachage qui soit un polynôme.
Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à vos yeux
C'était une bonne fonction au départ (et pas faite par un dilettante dans son garage), ça ne l'est plus.
marioski
Le lundi 25 janvier 2016 13:14:57 UTC+1, Nicolas George a écrit :
MAIxxx , dans le message <n84v6o$h81$, a écrit : >>> La fonction f peut être arithmétique quelconque, par exemple un p olynôme.
> Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été > inventé par un dilettante dans son garage.
En effet, mais CHAP n'utilise pas une fonction de hachage qui soit un polynôme.
> Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à v os > yeux
C'était une bonne fonction au départ (et pas faite par un dilettante dans son garage), ça ne l'est plus.
autre question: un pirate peut-il intercepter en temps réel un mot de passe? Je veux dire que si le mot de passe de la victime pouvait changer automatiq uement,disons toutes le minutes,un pirate aurait-il le savoir et le temps p our l'intercepter et l'utiliser au bon moment?
Le lundi 25 janvier 2016 13:14:57 UTC+1, Nicolas George a écrit :
MAIxxx , dans le message <n84v6o$h81$1@dont-email.me>, a écrit :
>>> La fonction f peut être arithmétique quelconque, par exemple un p olynôme.
> Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été
> inventé par un dilettante dans son garage.
En effet, mais CHAP n'utilise pas une fonction de hachage qui soit un
polynôme.
> Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à v os
> yeux
C'était une bonne fonction au départ (et pas faite par un dilettante dans
son garage), ça ne l'est plus.
autre question:
un pirate peut-il intercepter en temps réel un mot de passe?
Je veux dire que si le mot de passe de la victime pouvait changer automatiq uement,disons toutes le minutes,un pirate aurait-il le savoir et le temps p our l'intercepter et l'utiliser au bon moment?
Le lundi 25 janvier 2016 13:14:57 UTC+1, Nicolas George a écrit :
MAIxxx , dans le message <n84v6o$h81$, a écrit : >>> La fonction f peut être arithmétique quelconque, par exemple un p olynôme.
> Je ne crois pas que CHAP (RFC 1994) (PAP n'est pas sécurisé) ait été > inventé par un dilettante dans son garage.
En effet, mais CHAP n'utilise pas une fonction de hachage qui soit un polynôme.
> Mais si MD5 n'est pas forcément une "bonne" fonction de hachage à v os > yeux
C'était une bonne fonction au départ (et pas faite par un dilettante dans son garage), ça ne l'est plus.
autre question: un pirate peut-il intercepter en temps réel un mot de passe? Je veux dire que si le mot de passe de la victime pouvait changer automatiq uement,disons toutes le minutes,un pirate aurait-il le savoir et le temps p our l'intercepter et l'utiliser au bon moment?
Nicolas George
marioski , dans le message , a écrit :
un pirate peut-il intercepter en temps réel un mot de passe?
Trop vague.
Je veux dire que si le mot de passe de la victime pouvait changer automatiquement,disons toutes le minutes,un pirate aurait-il le savoir et le temps pour l'intercepter et l'utiliser au bon moment?
Une minute, c'est très long.
marioski , dans le message
<79cad33d-3ac8-4b2c-942b-f8176920dd89@googlegroups.com>, a écrit :
un pirate peut-il intercepter en temps réel un mot de passe?
Trop vague.
Je veux dire que si le mot de passe de la victime pouvait changer
automatiquement,disons toutes le minutes,un pirate aurait-il le savoir et
le temps pour l'intercepter et l'utiliser au bon moment?
un pirate peut-il intercepter en temps réel un mot de passe?
Trop vague.
Je veux dire que si le mot de passe de la victime pouvait changer automatiquement,disons toutes le minutes,un pirate aurait-il le savoir et le temps pour l'intercepter et l'utiliser au bon moment?
