Quel logiciel libre de génération de mots de passe ?
16 réponses
David MENTRE
Bonjour,
Je cherche un logiciel libre de génération aléatoire de mots de passe de
« bonne qualité ».
Jusqu'à maintenant j'utilisais /pwgen/ mais il y a un peu trop de
répétition à mon goût dans l'algorithme par défaut pour les mots de
passe facilement mémorisables. Il a une option « --secure » (/completely
random, hard-to-memorize paswords/) mais il n'y a pas de doc sur ce que
fait le logiciel dans ce cas.
Est-ce que quelqu'un connait un bon logiciel ou une bonne méthode pour
générer des mots de passe de qualité ? Une solution simple est peut-être
de prendre 48 ou 64 bits de /dev/random et de le passer dans un encodeur
binaire vers ASCII ?
Quelques questions supplémentaires sur ton programme.
J'ai modifié le programme pour le rendre plus lisible (pas sûr d'y avoir réussi). Toute critique, même négative, est bienvenue.
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
l.87: If each password takes 1ms to test ... 69 years
un memcmp(,, 10) prends de l'ordre de 10^-5 ms, soit 6 hrs.
(un temps d'attaque qui ne donne pas son contexte (direct ou via réseau lent, etc) ne veut rien dire).
Sylvain.
fabrice-pas-despame.bacchella
On Thu, 27 Jul 2006 02:08:50 +0200, Sylvain wrote:
On est totalement hors sujet là, mais bon, histoire de pinailler.
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
C'est surtout pas du tout la même chose, fread/fopen sont un enrobage bufférisé de read/open. Le premier est dans ISO C90, le second dans POSIX.1, c'est pas la cata comme portabilité.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Ben vous avez tord, un compilo un peu correct est très certainement capable de faire ça & beaucoup plus encore. Faite un man gcc & compter le nombre de paramètre -f..., notamment -fmove-loop-invariants, -funswitch-loops, ça doit être dans le contexte je pense.
On Thu, 27 Jul 2006 02:08:50 +0200, Sylvain <noSpam@mail.net> wrote:
On est totalement hors sujet là, mais bon, histoire de pinailler.
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
C'est surtout pas du tout la même chose, fread/fopen sont un enrobage
bufférisé de read/open. Le premier est dans ISO C90, le second dans
POSIX.1, c'est pas la cata comme portabilité.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule
fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Ben vous avez tord, un compilo un peu correct est très certainement
capable de faire ça & beaucoup plus encore. Faite un man gcc & compter
le nombre de paramètre -f..., notamment -fmove-loop-invariants,
-funswitch-loops, ça doit être dans le contexte je pense.
On Thu, 27 Jul 2006 02:08:50 +0200, Sylvain wrote:
On est totalement hors sujet là, mais bon, histoire de pinailler.
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
C'est surtout pas du tout la même chose, fread/fopen sont un enrobage bufférisé de read/open. Le premier est dans ISO C90, le second dans POSIX.1, c'est pas la cata comme portabilité.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Ben vous avez tord, un compilo un peu correct est très certainement capable de faire ça & beaucoup plus encore. Faite un man gcc & compter le nombre de paramètre -f..., notamment -fmove-loop-invariants, -funswitch-loops, ça doit être dans le contexte je pense.
David MENTRE
Bonjour Sylvain,
Sylvain writes:
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
Mouais. read/open fait parti du C. Et c'est beaucoup plus simple, donc je laisse comme ça.
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
Effectivement, d'après l'annexe A.6 du K&R (version française).
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Je me fiche un peu de l'optimisation, vu le nombre de fois que cette boucle est évaluée. Pour moi, c'est plus lisible écrit comme ça.
l.87: If each password takes 1ms to test ... 69 years
un memcmp(,, 10) prends de l'ordre de 10^-5 ms, soit 6 hrs.
(un temps d'attaque qui ne donne pas son contexte (direct ou via réseau lent, etc) ne veut rien dire).
Effectivement. Le commentaire visait surtout à me donner un ordre de grandeur (si le temps d'essai diminue d'un facteur 1000, il faut 6 mois pour tester toutes les combinaisons). J'ai mis un commentaire en ce sens.
J'ai mis à jour le programme, avec une précision sur la licence de Thomas : http://www.linux-france.org/~dmentre/code/dev-random-pass-gen.c
Merci pour la relecture, Amicalement, d. -- David Mentré
Bonjour Sylvain,
Sylvain <noSpam@mail.net> writes:
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
Mouais. read/open fait parti du C. Et c'est beaucoup plus simple, donc
je laisse comme ça.
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
Effectivement, d'après l'annexe A.6 du K&R (version française).
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule
fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Je me fiche un peu de l'optimisation, vu le nombre de fois que cette
boucle est évaluée. Pour moi, c'est plus lisible écrit comme ça.
l.87: If each password takes 1ms to test ... 69 years
un memcmp(,, 10) prends de l'ordre de 10^-5 ms, soit 6 hrs.
(un temps d'attaque qui ne donne pas son contexte (direct ou via réseau
lent, etc) ne veut rien dire).
Effectivement. Le commentaire visait surtout à me donner un ordre de
grandeur (si le temps d'essai diminue d'un facteur 1000, il faut 6 mois
pour tester toutes les combinaisons). J'ai mis un commentaire en ce
sens.
J'ai mis à jour le programme, avec une précision sur la licence de
Thomas : http://www.linux-france.org/~dmentre/code/dev-random-pass-gen.c
Merci pour la relecture,
Amicalement,
d.
--
David Mentré
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
Mouais. read/open fait parti du C. Et c'est beaucoup plus simple, donc je laisse comme ça.
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
Effectivement, d'après l'annexe A.6 du K&R (version française).
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Je me fiche un peu de l'optimisation, vu le nombre de fois que cette boucle est évaluée. Pour moi, c'est plus lisible écrit comme ça.
l.87: If each password takes 1ms to test ... 69 years
un memcmp(,, 10) prends de l'ordre de 10^-5 ms, soit 6 hrs.
(un temps d'attaque qui ne donne pas son contexte (direct ou via réseau lent, etc) ne veut rien dire).
Effectivement. Le commentaire visait surtout à me donner un ordre de grandeur (si le temps d'essai diminue d'un facteur 1000, il faut 6 mois pour tester toutes les combinaisons). J'ai mis un commentaire en ce sens.
J'ai mis à jour le programme, avec une précision sur la licence de Thomas : http://www.linux-france.org/~dmentre/code/dev-random-pass-gen.c
Merci pour la relecture, Amicalement, d. -- David Mentré
Erwan David
David MENTRE écrivait :
Bonjour Sylvain,
Sylvain writes:
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
Mouais. read/open fait parti du C. Et c'est beaucoup plus simple, donc je laisse comme ça.
Non read/open c'est du Posix. C ne connais que fread/fopen
-- Erwan
David MENTRE <david.mentre@gmail.com> écrivait :
Bonjour Sylvain,
Sylvain <noSpam@mail.net> writes:
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
Mouais. read/open fait parti du C. Et c'est beaucoup plus simple, donc
je laisse comme ça.
Non read/open c'est du Posix. C ne connais que fread/fopen
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
Mouais. read/open fait parti du C. Et c'est beaucoup plus simple, donc je laisse comme ça.
Non read/open c'est du Posix. C ne connais que fread/fopen, et encore en mode hébergé, pas en mode freestanding.
-- Erwan
pornin
According to Sylvain :
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
D'un autre côté, pour trouver une machine où il y a un /dev/random mais pas de open() ni read(), il faut s'accrocher...
(Note : mon code originel utilisait /dev/urandom, pas /dev/random. C'était voulu. Suivant les OS, /dev/random peut bloquer, sans limite sur le temps, ce qui peut être très pénible. /dev/urandom -- s'il est correctement initialisé, ce qui incombe, sous Linux, aux scripts de boot de la distribution -- n'a pas ce défaut et fait parfaitement l'affaire cryptographiquement.)
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
La valeur maximale de x n'entre pas en ligne de compte ; on écrit dans une variable non signée, donc la troncature se passe "bien". Dans tous les cas, la conversion en "unsigned" est faite, au moins implicitement ; expliciter cette conversion ne change donc pas le code produit par le compilateur. C'est une forme de commentaire, censée indiquer au programmeur que oui, il y a changement de type (et donc motif de méfiance), mais c'est voulu et contrôlé.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Pour les valeurs considérées ici (avec max valant 10 ou 26), le nombre moyen d'évaluation de la boucle sera de 1.094 (pour max = 26) ou de 1.024 (pour max = 10). Autrement dit, le surcoût maximal de la deuxième division est de 9.4%, ce qui est assez misérable, en fait.
Si néanmoins on s'inquiète de vitesse dans ce cas, alors il faut ne pas faire la division du tout, ce qui se fait en spécialisant la fonction randval() : randval10() pour le cas max = 10, randval26() pour le cas max = 26, et constante inscrite en dur dans le programme (respectivement 250 et 234).
Mais il est fort douteux que cela ait une quelconque influence détectable ici ; mieux vaut alors se contenter du code compact et lisible.
--Thomas Pornin
According to Sylvain <noSpam@mail.net>:
l.34,72 read/open
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
D'un autre côté, pour trouver une machine où il y a un /dev/random mais
pas de open() ni read(), il faut s'accrocher...
(Note : mon code originel utilisait /dev/urandom, pas /dev/random.
C'était voulu. Suivant les OS, /dev/random peut bloquer, sans limite
sur le temps, ce qui peut être très pénible. /dev/urandom -- s'il est
correctement initialisé, ce qui incombe, sous Linux, aux scripts de boot
de la distribution -- n'a pas ce défaut et fait parfaitement l'affaire
cryptographiquement.)
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
La valeur maximale de x n'entre pas en ligne de compte ; on écrit
dans une variable non signée, donc la troncature se passe "bien".
Dans tous les cas, la conversion en "unsigned" est faite, au moins
implicitement ; expliciter cette conversion ne change donc pas le code
produit par le compilateur. C'est une forme de commentaire, censée
indiquer au programmeur que oui, il y a changement de type (et donc
motif de méfiance), mais c'est voulu et contrôlé.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule
fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Pour les valeurs considérées ici (avec max valant 10 ou 26), le nombre
moyen d'évaluation de la boucle sera de 1.094 (pour max = 26) ou de
1.024 (pour max = 10). Autrement dit, le surcoût maximal de la deuxième
division est de 9.4%, ce qui est assez misérable, en fait.
Si néanmoins on s'inquiète de vitesse dans ce cas, alors il faut ne pas
faire la division du tout, ce qui se fait en spécialisant la fonction
randval() : randval10() pour le cas max = 10, randval26() pour le cas
max = 26, et constante inscrite en dur dans le programme (respectivement
250 et 234).
Mais il est fort douteux que cela ait une quelconque influence détectable
ici ; mieux vaut alors se contenter du code compact et lisible.
fread/fopen de stdio.h seraient plus portable que read/open de unistd.h
D'un autre côté, pour trouver une machine où il y a un /dev/random mais pas de open() ni read(), il faut s'accrocher...
(Note : mon code originel utilisait /dev/urandom, pas /dev/random. C'était voulu. Suivant les OS, /dev/random peut bloquer, sans limite sur le temps, ce qui peut être très pénible. /dev/urandom -- s'il est correctement initialisé, ce qui incombe, sous Linux, aux scripts de boot de la distribution -- n'a pas ce défaut et fait parfaitement l'affaire cryptographiquement.)
l.44: val = (unsigned)x;
x est unsigned et plus petit que val, le cast ne sert à rien.
La valeur maximale de x n'entre pas en ligne de compte ; on écrit dans une variable non signée, donc la troncature se passe "bien". Dans tous les cas, la conversion en "unsigned" est faite, au moins implicitement ; expliciter cette conversion ne change donc pas le code produit par le compilateur. C'est une forme de commentaire, censée indiquer au programmeur que oui, il y a changement de type (et donc motif de méfiance), mais c'est voulu et contrôlé.
l.45: while (val >= max * (256 / max));
"max * (256 / max)" est une constante qui devrait être évalué un seule fois (je ne laisserais pas l'optim au bon vouloir du compilo).
Pour les valeurs considérées ici (avec max valant 10 ou 26), le nombre moyen d'évaluation de la boucle sera de 1.094 (pour max = 26) ou de 1.024 (pour max = 10). Autrement dit, le surcoût maximal de la deuxième division est de 9.4%, ce qui est assez misérable, en fait.
Si néanmoins on s'inquiète de vitesse dans ce cas, alors il faut ne pas faire la division du tout, ce qui se fait en spécialisant la fonction randval() : randval10() pour le cas max = 10, randval26() pour le cas max = 26, et constante inscrite en dur dans le programme (respectivement 250 et 234).
Mais il est fort douteux que cela ait une quelconque influence détectable ici ; mieux vaut alors se contenter du code compact et lisible.
