Sinon, ben oui, le concept général en cryptographie est que ce qui distingue un utilisateur donné de n'importe qui d'autre, c'est son accès à certaines données secrètes.
le "ce-que-je-sais" (le PIN) est généralement couplé au "ce-que-j'ai" (une carte par exemple); l'élément physique est absent dans votre système (oui, on peut le voler, c'est pour cela qu'on multiplie les éléments -- et que l'on introduit le "ce-que-je-suis" (empreinte bio)).
Mais ce n'est pas pour la clé privée le niveau de sécurité des cartes à puce. Si la sécurité du poste où la clé est utilisé n'est pas assurée, la clé peut être volée.
si le point s'applique à une carte, on envisage une bien mauvaise carte, on peut voler la carte soit, mais pas en extraire la clé (enfin,si c'est pas fait n'importe comment).
Mouaif. Si la sécurité du poste où une carte à puce est utilisée n'est pas assurée, un attaquant peut faire signer en douce une centaine de messages pendant les quelques secondes où la carte est présente et débloquée. La nuance entre ça et le vol pur et simple de la clé est quelque chose d'assez ténu.
à nuancer, vous parlez de signature "à valeur juridique", la règle vaut alors que le déblocaque ne vaut que pour une seule signature; N signatures imposant N saisies du PIN (qui doit évidemment être saisis sur un périphérique propre ou au tout le moins ne pas être rejouable).
Je vois un avantage réel à votre solution par rapport au certificat logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas récupérer la clé.
une clé stockée à demeure en clair ?? ça ne devrait pas exister.
C'est toute l'idée : calculs en local, mais aucun stockage local. Les moyens de signature ne sont présent sur le poste client que pendant le temps où le poste client est physiquement protégé par l'utilisateur (quand il est devant, donc).
"quand il est devant" ??? le plug-in se nettoie tout partout dès que je tourne le dos ? c'est bien ça !! ;)
Ce que l'on pourrait obtenir avec un certificat logiciel si on trouvait un moyen de faire en sorte que le mot de passe résiste totalement à la force brute/dictionnaire.
une clé type PGP est protégée exactement comme votre cert qui descends chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur pas du système.
Sylvain.
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
Sinon, ben oui, le concept général en cryptographie est que ce qui
distingue un utilisateur donné de n'importe qui d'autre, c'est son
accès à certaines données secrètes.
le "ce-que-je-sais" (le PIN) est généralement couplé au "ce-que-j'ai"
(une carte par exemple); l'élément physique est absent dans votre
système (oui, on peut le voler, c'est pour cela qu'on multiplie les
éléments -- et que l'on introduit le "ce-que-je-suis" (empreinte bio)).
Mais ce n'est pas pour la clé privée le niveau de sécurité des cartes
à puce. Si la sécurité du poste où la clé est utilisé n'est pas
assurée, la clé peut être volée.
si le point s'applique à une carte, on envisage une bien mauvaise carte,
on peut voler la carte soit, mais pas en extraire la clé (enfin,si c'est
pas fait n'importe comment).
Mouaif. Si la sécurité du poste où une carte à puce est utilisée n'est
pas assurée, un attaquant peut faire signer en douce une centaine de
messages pendant les quelques secondes où la carte est présente et
débloquée. La nuance entre ça et le vol pur et simple de la clé est
quelque chose d'assez ténu.
à nuancer, vous parlez de signature "à valeur juridique", la règle vaut
alors que le déblocaque ne vaut que pour une seule signature; N
signatures imposant N saisies du PIN (qui doit évidemment être saisis
sur un périphérique propre ou au tout le moins ne pas être rejouable).
Je vois un avantage réel à votre solution par rapport au certificat
logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas
récupérer la clé.
une clé stockée à demeure en clair ?? ça ne devrait pas exister.
C'est toute l'idée : calculs en local, mais aucun stockage local. Les
moyens de signature ne sont présent sur le poste client que pendant le
temps où le poste client est physiquement protégé par l'utilisateur
(quand il est devant, donc).
"quand il est devant" ??? le plug-in se nettoie tout partout dès que je
tourne le dos ? c'est bien ça !! ;)
Ce que l'on pourrait obtenir avec un certificat logiciel si on
trouvait un moyen de faire en sorte que le mot de passe résiste
totalement à la force brute/dictionnaire.
une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur
pas du système.
Sinon, ben oui, le concept général en cryptographie est que ce qui distingue un utilisateur donné de n'importe qui d'autre, c'est son accès à certaines données secrètes.
le "ce-que-je-sais" (le PIN) est généralement couplé au "ce-que-j'ai" (une carte par exemple); l'élément physique est absent dans votre système (oui, on peut le voler, c'est pour cela qu'on multiplie les éléments -- et que l'on introduit le "ce-que-je-suis" (empreinte bio)).
Mais ce n'est pas pour la clé privée le niveau de sécurité des cartes à puce. Si la sécurité du poste où la clé est utilisé n'est pas assurée, la clé peut être volée.
si le point s'applique à une carte, on envisage une bien mauvaise carte, on peut voler la carte soit, mais pas en extraire la clé (enfin,si c'est pas fait n'importe comment).
Mouaif. Si la sécurité du poste où une carte à puce est utilisée n'est pas assurée, un attaquant peut faire signer en douce une centaine de messages pendant les quelques secondes où la carte est présente et débloquée. La nuance entre ça et le vol pur et simple de la clé est quelque chose d'assez ténu.
à nuancer, vous parlez de signature "à valeur juridique", la règle vaut alors que le déblocaque ne vaut que pour une seule signature; N signatures imposant N saisies du PIN (qui doit évidemment être saisis sur un périphérique propre ou au tout le moins ne pas être rejouable).
Je vois un avantage réel à votre solution par rapport au certificat logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas récupérer la clé.
une clé stockée à demeure en clair ?? ça ne devrait pas exister.
C'est toute l'idée : calculs en local, mais aucun stockage local. Les moyens de signature ne sont présent sur le poste client que pendant le temps où le poste client est physiquement protégé par l'utilisateur (quand il est devant, donc).
"quand il est devant" ??? le plug-in se nettoie tout partout dès que je tourne le dos ? c'est bien ça !! ;)
Ce que l'on pourrait obtenir avec un certificat logiciel si on trouvait un moyen de faire en sorte que le mot de passe résiste totalement à la force brute/dictionnaire.
une clé type PGP est protégée exactement comme votre cert qui descends chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur pas du système.
Sylvain.
Jean-Marc Desperrier
Sylvain wrote:
According to Jean-Marc Desperrier :
Je vois un avantage réel à votre solution par rapport au certificat logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas récupérer la clé.
une clé stockée à demeure en clair ?? ça ne devrait pas exister.
[...] une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur pas du système.
Pourtant avec ce que j'ai précisé juste après, je croyais que mon idée était plutôt claire.
Avec les mots de passe qu'utilisent 99% des utilisateurs, si quelqu'un peut récupérer le container de la clé, il lui faut très peu de moyen pour retrouver le mot de passe.
Avec un bon dictionnaire, et des méthodes assez efficaces, il est possible de casser à peu prêt n'importe quoi. On impose des chiffres dans le mot de passe ? En général, il sont à la fin. L'utilisateur prend une longue phrase et n'en garde que les initiales pour le mot de passe ? Il suffit d'adapter l'algo à cela, les règles de grammaire limitent sérieusement l'espace des phrases ayant un sens, certaines initiales vont revenir souvent suivant des schéma prévisibles, etc ...
Si on veut que le mot de passe soit parfaitement solide, il faut qu'il ait 128 bits d'entropie prouvable, *et* que l'utilisateur lambda puisse s'en rappeler. Je ne connais aucune méthode à l'heure actuelle qui permette d'arriver à cela.
Sylvain wrote:
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
Je vois un avantage réel à votre solution par rapport au certificat
logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas
récupérer la clé.
une clé stockée à demeure en clair ?? ça ne devrait pas exister.
[...]
une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur
pas du système.
Pourtant avec ce que j'ai précisé juste après, je croyais que mon idée
était plutôt claire.
Avec les mots de passe qu'utilisent 99% des utilisateurs, si quelqu'un
peut récupérer le container de la clé, il lui faut très peu de moyen
pour retrouver le mot de passe.
Avec un bon dictionnaire, et des méthodes assez efficaces, il est
possible de casser à peu prêt n'importe quoi. On impose des chiffres
dans le mot de passe ? En général, il sont à la fin. L'utilisateur prend
une longue phrase et n'en garde que les initiales pour le mot de passe ?
Il suffit d'adapter l'algo à cela, les règles de grammaire limitent
sérieusement l'espace des phrases ayant un sens, certaines initiales
vont revenir souvent suivant des schéma prévisibles, etc ...
Si on veut que le mot de passe soit parfaitement solide, il faut qu'il
ait 128 bits d'entropie prouvable, *et* que l'utilisateur lambda puisse
s'en rappeler. Je ne connais aucune méthode à l'heure actuelle qui
permette d'arriver à cela.
Je vois un avantage réel à votre solution par rapport au certificat logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas récupérer la clé.
une clé stockée à demeure en clair ?? ça ne devrait pas exister.
[...] une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur pas du système.
Pourtant avec ce que j'ai précisé juste après, je croyais que mon idée était plutôt claire.
Avec les mots de passe qu'utilisent 99% des utilisateurs, si quelqu'un peut récupérer le container de la clé, il lui faut très peu de moyen pour retrouver le mot de passe.
Avec un bon dictionnaire, et des méthodes assez efficaces, il est possible de casser à peu prêt n'importe quoi. On impose des chiffres dans le mot de passe ? En général, il sont à la fin. L'utilisateur prend une longue phrase et n'en garde que les initiales pour le mot de passe ? Il suffit d'adapter l'algo à cela, les règles de grammaire limitent sérieusement l'espace des phrases ayant un sens, certaines initiales vont revenir souvent suivant des schéma prévisibles, etc ...
Si on veut que le mot de passe soit parfaitement solide, il faut qu'il ait 128 bits d'entropie prouvable, *et* que l'utilisateur lambda puisse s'en rappeler. Je ne connais aucune méthode à l'heure actuelle qui permette d'arriver à cela.
Jean-Marc Desperrier
Thomas Pornin wrote:
Les serveurs limitent le nombre d'essais sur un compte à un certain débit (quelques essais par tranche de 5 minutes, en gros). Bloquer le compte permet à n'importe quel quidam de bloquer les comptes de n'importe qui, ce qui n'est pas acceptable.
Oui, je ne voulait pas dire un blocage définitive, uniquement temporaire, mais en même temps ce genre de système est sensible à une attaque basée sur du social engineering pour deviner le genre de mot de passe que l'utilisateur a pu utiliser.
Je me souviens d'un cas comme cela où j'ai pu trouver le mot de passe d'une personne travaillant avec moi au premier essai. Au bout de quelque jours passé à travailler avec elle, d'un coup d'oeil sur son bureau, on pouvait avoir une idée sur ce qu'il risquait d'être. Non, il n'était pas écrit sur le bureau, mais était en rapport avec quelque chose d'exposé dessus.
Si vous n'avez aucun filtrage sur les mots de passe, que même ceux très faible sont acceptés (il n'est pas toujours évident de voir sans info sur l'utilisateur que le mot est *très* faible), il y a un risque.
Hotmail gère ce genre de chose en prévenant l'utilisateur au prochain login qu'il y a eu plusieurs essais de mot de passe avec erreur.
Thomas Pornin wrote:
Les serveurs limitent le nombre d'essais sur un compte à un certain
débit (quelques essais par tranche de 5 minutes, en gros). Bloquer
le compte permet à n'importe quel quidam de bloquer les comptes de
n'importe qui, ce qui n'est pas acceptable.
Oui, je ne voulait pas dire un blocage définitive, uniquement
temporaire, mais en même temps ce genre de système est sensible à une
attaque basée sur du social engineering pour deviner le genre de mot de
passe que l'utilisateur a pu utiliser.
Je me souviens d'un cas comme cela où j'ai pu trouver le mot de passe
d'une personne travaillant avec moi au premier essai. Au bout de quelque
jours passé à travailler avec elle, d'un coup d'oeil sur son bureau, on
pouvait avoir une idée sur ce qu'il risquait d'être. Non, il n'était pas
écrit sur le bureau, mais était en rapport avec quelque chose d'exposé
dessus.
Si vous n'avez aucun filtrage sur les mots de passe, que même ceux très
faible sont acceptés (il n'est pas toujours évident de voir sans info
sur l'utilisateur que le mot est *très* faible), il y a un risque.
Hotmail gère ce genre de chose en prévenant l'utilisateur au prochain
login qu'il y a eu plusieurs essais de mot de passe avec erreur.
Les serveurs limitent le nombre d'essais sur un compte à un certain débit (quelques essais par tranche de 5 minutes, en gros). Bloquer le compte permet à n'importe quel quidam de bloquer les comptes de n'importe qui, ce qui n'est pas acceptable.
Oui, je ne voulait pas dire un blocage définitive, uniquement temporaire, mais en même temps ce genre de système est sensible à une attaque basée sur du social engineering pour deviner le genre de mot de passe que l'utilisateur a pu utiliser.
Je me souviens d'un cas comme cela où j'ai pu trouver le mot de passe d'une personne travaillant avec moi au premier essai. Au bout de quelque jours passé à travailler avec elle, d'un coup d'oeil sur son bureau, on pouvait avoir une idée sur ce qu'il risquait d'être. Non, il n'était pas écrit sur le bureau, mais était en rapport avec quelque chose d'exposé dessus.
Si vous n'avez aucun filtrage sur les mots de passe, que même ceux très faible sont acceptés (il n'est pas toujours évident de voir sans info sur l'utilisateur que le mot est *très* faible), il y a un risque.
Hotmail gère ce genre de chose en prévenant l'utilisateur au prochain login qu'il y a eu plusieurs essais de mot de passe avec erreur.
remy
taper (1) coup de pub taper (2)demande d'audite informel taper (3) pas toucher
a+ remy
taper
(1) coup de pub
taper
(2)demande d'audite informel
taper
(3) pas toucher
taper (1) coup de pub taper (2)demande d'audite informel taper (3) pas toucher
a+ remy
pornin
According to Jean-Marc Desperrier :
Je me souviens d'un cas comme cela où j'ai pu trouver le mot de passe d'une personne travaillant avec moi au premier essai. Au bout de quelque jours passé à travailler avec elle, d'un coup d'oeil sur son bureau, on pouvait avoir une idée sur ce qu'il risquait d'être. Non, il n'était pas écrit sur le bureau, mais était en rapport avec quelque chose d'exposé dessus.
C'est un ennui générique de beaucoup de systèmes de sécurité : l'utilisateur est un ennemi. En général, non seulement l'utilisateur moyen n'est pas capable (car pas formé adéquatement) de réaliser correctement sa partie de la procédure de sécurité (ici, choisir un mot de passe "solide") mais en plus il va faire des pieds et des mains pour combattre toute procédure qu'il juge contraignante (écrire le mot de passe sur un post-it collé sous le clavier -- ou encore, comme montré dans une publicité récente, utiliser le code inscrit dans l'oreille du chien).
Ces problèmes ne peuvent pas tous être contournés par le logiciel ou le matériel. Le logiciel/matériel peut encadrer l'utilisateur et le contraindre dans une certaine mesure, mais, ultimement, il faut que l'utilisateur coopère ou au moins se laisse faire, ce qui suppose une formation ou au moins une motivation incontournable (i.e., la procédure est respectée à la lettre, ou c'est la cour martiale).
--Thomas Pornin
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
Je me souviens d'un cas comme cela où j'ai pu trouver le mot de passe
d'une personne travaillant avec moi au premier essai. Au bout de
quelque jours passé à travailler avec elle, d'un coup d'oeil sur son
bureau, on pouvait avoir une idée sur ce qu'il risquait d'être. Non,
il n'était pas écrit sur le bureau, mais était en rapport avec quelque
chose d'exposé dessus.
C'est un ennui générique de beaucoup de systèmes de sécurité :
l'utilisateur est un ennemi. En général, non seulement l'utilisateur
moyen n'est pas capable (car pas formé adéquatement) de réaliser
correctement sa partie de la procédure de sécurité (ici, choisir un mot
de passe "solide") mais en plus il va faire des pieds et des mains pour
combattre toute procédure qu'il juge contraignante (écrire le mot de
passe sur un post-it collé sous le clavier -- ou encore, comme montré
dans une publicité récente, utiliser le code inscrit dans l'oreille du
chien).
Ces problèmes ne peuvent pas tous être contournés par le logiciel ou
le matériel. Le logiciel/matériel peut encadrer l'utilisateur et le
contraindre dans une certaine mesure, mais, ultimement, il faut que
l'utilisateur coopère ou au moins se laisse faire, ce qui suppose une
formation ou au moins une motivation incontournable (i.e., la procédure
est respectée à la lettre, ou c'est la cour martiale).
Je me souviens d'un cas comme cela où j'ai pu trouver le mot de passe d'une personne travaillant avec moi au premier essai. Au bout de quelque jours passé à travailler avec elle, d'un coup d'oeil sur son bureau, on pouvait avoir une idée sur ce qu'il risquait d'être. Non, il n'était pas écrit sur le bureau, mais était en rapport avec quelque chose d'exposé dessus.
C'est un ennui générique de beaucoup de systèmes de sécurité : l'utilisateur est un ennemi. En général, non seulement l'utilisateur moyen n'est pas capable (car pas formé adéquatement) de réaliser correctement sa partie de la procédure de sécurité (ici, choisir un mot de passe "solide") mais en plus il va faire des pieds et des mains pour combattre toute procédure qu'il juge contraignante (écrire le mot de passe sur un post-it collé sous le clavier -- ou encore, comme montré dans une publicité récente, utiliser le code inscrit dans l'oreille du chien).
Ces problèmes ne peuvent pas tous être contournés par le logiciel ou le matériel. Le logiciel/matériel peut encadrer l'utilisateur et le contraindre dans une certaine mesure, mais, ultimement, il faut que l'utilisateur coopère ou au moins se laisse faire, ce qui suppose une formation ou au moins une motivation incontournable (i.e., la procédure est respectée à la lettre, ou c'est la cour martiale).
--Thomas Pornin
remy
C'est un ennui générique de beaucoup de systèmes de sécurité : l'utilisateur est un ennemi. En général,
bon comme tu ne veux pas taper (2) et que je ne dois pas etre le seul a avoir fait le lien
je dirais que parfois les defauts viennent aussi du concepteur regarde les msg que tu as postes ici
oui oui je sais ce n'est pas le meme generateur et il y a de "l'alea"
perso je mettrais en place un leurre compte bidon qd il y a detection intrusion
ps le fait que cela soit public et pour que le generateur change pas pour te compliquer la vie
by remy
C'est un ennui générique de beaucoup de systèmes de sécurité :
l'utilisateur est un ennemi. En général,
bon comme tu ne veux pas taper (2)
et que je ne dois pas etre le seul a avoir fait le lien
je dirais que parfois les defauts viennent aussi du concepteur
regarde les msg que tu as postes ici
oui oui je sais ce n'est pas le meme generateur
et il y a de "l'alea"
perso je mettrais en place un leurre compte bidon
qd il y a detection intrusion
ps le fait que cela soit public et pour que le generateur change
pas pour te compliquer la vie
C'est un ennui générique de beaucoup de systèmes de sécurité : l'utilisateur est un ennemi. En général,
bon comme tu ne veux pas taper (2) et que je ne dois pas etre le seul a avoir fait le lien
je dirais que parfois les defauts viennent aussi du concepteur regarde les msg que tu as postes ici
oui oui je sais ce n'est pas le meme generateur et il y a de "l'alea"
perso je mettrais en place un leurre compte bidon qd il y a detection intrusion
ps le fait que cela soit public et pour que le generateur change pas pour te compliquer la vie
by remy
*core*administrator
On Fri, 4 Mar 2005 09:34:00 +0000 (UTC), (Thomas Pornin) wrote:
Ces problèmes ne peuvent pas tous être contournés par le logiciel ou le matériel. Le logiciel/matériel peut encadrer l'utilisateur et le contraindre dans une certaine mesure, mais, ultimement, il faut que l'utilisateur coopère ou au moins se laisse faire, ce qui suppose une formation ou au moins une motivation incontournable (i.e., la procédure est respectée à la lettre, ou c'est la cour martiale).
La solution logique aux problèmes bien connus concernant les mots
de passe n'est-il pas, à terme, la suppression complète de ceux-ci et leur remplacement par des moyens technologiques de substitution telle la biométrie ?
On Fri, 4 Mar 2005 09:34:00 +0000 (UTC), pornin@nerim.net (Thomas
Pornin) wrote:
Ces problèmes ne peuvent pas tous être contournés par le logiciel ou
le matériel. Le logiciel/matériel peut encadrer l'utilisateur et le
contraindre dans une certaine mesure, mais, ultimement, il faut que
l'utilisateur coopère ou au moins se laisse faire, ce qui suppose une
formation ou au moins une motivation incontournable (i.e., la procédure
est respectée à la lettre, ou c'est la cour martiale).
La solution logique aux problèmes bien connus concernant les mots
de passe n'est-il pas, à terme, la suppression complète de ceux-ci et
leur remplacement par des moyens technologiques de substitution telle
la biométrie ?
On Fri, 4 Mar 2005 09:34:00 +0000 (UTC), (Thomas Pornin) wrote:
Ces problèmes ne peuvent pas tous être contournés par le logiciel ou le matériel. Le logiciel/matériel peut encadrer l'utilisateur et le contraindre dans une certaine mesure, mais, ultimement, il faut que l'utilisateur coopère ou au moins se laisse faire, ce qui suppose une formation ou au moins une motivation incontournable (i.e., la procédure est respectée à la lettre, ou c'est la cour martiale).
La solution logique aux problèmes bien connus concernant les mots
de passe n'est-il pas, à terme, la suppression complète de ceux-ci et leur remplacement par des moyens technologiques de substitution telle la biométrie ?
Sylvain
Sylvain wrote:
According to Jean-Marc Desperrier :
une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur pas du système.
Pourtant avec ce que j'ai précisé juste après, je croyais que mon idée était plutôt claire.
elle l'est et je ne pense pas l'avoir contredit - ou c'est moi qui n'était également pas clair.
Avec les mots de passe qu'utilisent 99% des utilisateurs, si quelqu'un peut récupérer le container de la clé, il lui faut très peu de moyen pour retrouver le mot de passe.
c'était mon point, (grossièrement) le PBE n'est fiable que lorsque des machines utilisent des vrais aléa préalablement échangés, mais dans un tel contexte elles devraient plutôt s'échanger des certs ...
Sylvain.
Sylvain wrote:
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur
pas du système.
Pourtant avec ce que j'ai précisé juste après, je croyais que mon idée
était plutôt claire.
elle l'est et je ne pense pas l'avoir contredit - ou c'est moi qui
n'était également pas clair.
Avec les mots de passe qu'utilisent 99% des utilisateurs, si quelqu'un
peut récupérer le container de la clé, il lui faut très peu de moyen
pour retrouver le mot de passe.
c'était mon point, (grossièrement) le PBE n'est fiable que lorsque des
machines utilisent des vrais aléa préalablement échangés, mais dans un
tel contexte elles devraient plutôt s'échanger des certs ...
une clé type PGP est protégée exactement comme votre cert qui descends
chiffré, la qualité du chiffrement PBE ne dépend que de l'utilisateur pas du système.
Pourtant avec ce que j'ai précisé juste après, je croyais que mon idée était plutôt claire.
elle l'est et je ne pense pas l'avoir contredit - ou c'est moi qui n'était également pas clair.
Avec les mots de passe qu'utilisent 99% des utilisateurs, si quelqu'un peut récupérer le container de la clé, il lui faut très peu de moyen pour retrouver le mot de passe.
c'était mon point, (grossièrement) le PBE n'est fiable que lorsque des machines utilisent des vrais aléa préalablement échangés, mais dans un tel contexte elles devraient plutôt s'échanger des certs ...
