Pour un bon mot de passe, il est d'usage de dire qu'il faut au moins
une minuscule, une majuscule, un chiffre et un caractère spécial.
Ça semble logique, mais finalement peut-être pas : un logiciel qui
cherche un mot de passe ne sais pas comment il est conçu, il ignore si
ce ne sont que des lettres minuscules par exemple, donc il cherche sur
la totalité des possibilités, non ?
Ou alors c'est parce que la recherche se fait dans un ordre ? Par
exemple d'abord les minuscules, puis les majuscules, puis les chiffres,
puis un mélange de 2, puis un mélange de 3... ?
Bruno Tréguier , dans le message <ikt5rm$3o1$, a écrit :
le seul aspect "logiciel" de la chose est que l'état du capteur physique est vraisemblablement reflété au niveau du firmware du lecteur par le positionnement d'un bit à 0 ou 1.
Précisément.
En revanche, les pilotes et l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce statut ou de l'ignorer.
Jusqu'au jour où ils trouvent comment uploader un nouveau firmware dans le lecteur. C'est un degré de protection, mais pas une protection absolue.
Bruno Tréguier
, dans le message <ikt5rm$3o1$1@typhon.shom.fr>, a écrit :
le seul aspect "logiciel" de la chose est que l'état du capteur
physique est vraisemblablement reflété au niveau du firmware du lecteur
par le positionnement d'un bit à 0 ou 1.
Précisément.
En revanche, les pilotes et
l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce
statut ou de l'ignorer.
Jusqu'au jour où ils trouvent comment uploader un nouveau firmware dans le
lecteur. C'est un degré de protection, mais pas une protection absolue.
Bruno Tréguier , dans le message <ikt5rm$3o1$, a écrit :
le seul aspect "logiciel" de la chose est que l'état du capteur physique est vraisemblablement reflété au niveau du firmware du lecteur par le positionnement d'un bit à 0 ou 1.
Précisément.
En revanche, les pilotes et l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce statut ou de l'ignorer.
Jusqu'au jour où ils trouvent comment uploader un nouveau firmware dans le lecteur. C'est un degré de protection, mais pas une protection absolue.
Dominique ROUSSEAU
Le ven, 04 mar 2011 at 04:20 GMT, Fabien LE LEZ a écrit :
Note que j'ai entendu beaucoup d'administrateurs système dire explicitement qu'ils ont mis ça en place pour se protéger contre d'éventuelles attaques.
Ca permet une double authentification, par exemple. En autorisant les connexions uniquement par clef, puis su/sudo/calife qui nécessite de connaitre un mot de passe.
Le ven, 04 mar 2011 at 04:20 GMT, Fabien LE LEZ <gramster@gramster.com> a écrit :
Note que j'ai entendu beaucoup d'administrateurs système dire
explicitement qu'ils ont mis ça en place pour se protéger contre
d'éventuelles attaques.
Ca permet une double authentification, par exemple.
En autorisant les connexions uniquement par clef, puis su/sudo/calife qui
nécessite de connaitre un mot de passe.
Le ven, 04 mar 2011 at 04:20 GMT, Fabien LE LEZ a écrit :
Note que j'ai entendu beaucoup d'administrateurs système dire explicitement qu'ils ont mis ça en place pour se protéger contre d'éventuelles attaques.
Ca permet une double authentification, par exemple. En autorisant les connexions uniquement par clef, puis su/sudo/calife qui nécessite de connaitre un mot de passe.
Yannix
Le 05/03/2011 10:01, Nicolas George a écrit :
Yannix , dans le message <iks9db$o2v$, a écrit :
Le truc du login sur une console distante (ou pas) c'est de commencer par taper un faux mot de passe au premier login et voir si il passe...
C'est assez idiot, ce « truc ».
Ah ? Et ben pourquoi ? Le "machin" te demande un mot de passe, tu commences par lui en donner un faux, et si jamais le "machin" te dit "ok" c'est qu'il est compromis. Non ?
Le truc, c'est de vérifier l'empreinte de clef de la machine distante, ni plus ni moins.
Ce qui est à la portée de tout le monde, par exemple lors d'un retrait au DAB, n'est-ce pas ?
X.
Le 05/03/2011 10:01, Nicolas George a écrit :
Yannix , dans le message <iks9db$o2v$1@speranza.aioe.org>, a écrit :
Le truc du login sur une console distante (ou pas) c'est de commencer
par taper un faux mot de passe au premier login et voir si il passe...
C'est assez idiot, ce « truc ».
Ah ? Et ben pourquoi ? Le "machin" te demande un mot de passe, tu
commences par lui en donner un faux, et si jamais le "machin" te dit
"ok" c'est qu'il est compromis. Non ?
Le truc, c'est de vérifier l'empreinte de
clef de la machine distante, ni plus ni moins.
Ce qui est à la portée de tout le monde, par exemple lors d'un retrait
au DAB, n'est-ce pas ?
Le truc du login sur une console distante (ou pas) c'est de commencer par taper un faux mot de passe au premier login et voir si il passe...
C'est assez idiot, ce « truc ».
Ah ? Et ben pourquoi ? Le "machin" te demande un mot de passe, tu commences par lui en donner un faux, et si jamais le "machin" te dit "ok" c'est qu'il est compromis. Non ?
Le truc, c'est de vérifier l'empreinte de clef de la machine distante, ni plus ni moins.
Ce qui est à la portée de tout le monde, par exemple lors d'un retrait au DAB, n'est-ce pas ?
X.
Kevin Denis
Le 04-03-2011, Benoit Izac a écrit :
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est contraignant.
Pas plus que si j'utilise une clé de chiffrement stockée sur la clé USB.
Le problème n'est pas la clé de chiffrement, mais le code en clair qui s'éxécute au démarrage et qui peut être modifié par un attaquant.
D'ailleurs je me demande si TPM ne pourrait pas apporter une aide dans ce processus (à vrai dire, ça fait une paye que je me dis que je vais me pencher dessus et je ne l'ai que survolé donc je ne sais pas vraiment).
Après, la sécurité, c'est de toujours contraignant et au final, c'est un compromis entre la facilité d'utilisation et la protection que l'on souhaite.
la bonne sécurité, c'est la sécurité pragmatique, qui n'est pas contraignante. Donc elle sera acceptée, utilisée. -- Kevin
Le 04-03-2011, Benoit Izac <use.reply.to@INVALID.ADDRESS> a écrit :
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est
contraignant.
Pas plus que si j'utilise une clé de chiffrement stockée sur la clé USB.
Le problème n'est pas la clé de chiffrement, mais le code en clair qui
s'éxécute au démarrage et qui peut être modifié par un attaquant.
D'ailleurs je me demande si TPM ne pourrait pas apporter une aide dans
ce processus (à vrai dire, ça fait une paye que je me dis que je vais me
pencher dessus et je ne l'ai que survolé donc je ne sais pas vraiment).
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est contraignant.
Pas plus que si j'utilise une clé de chiffrement stockée sur la clé USB.
Le problème n'est pas la clé de chiffrement, mais le code en clair qui s'éxécute au démarrage et qui peut être modifié par un attaquant.
D'ailleurs je me demande si TPM ne pourrait pas apporter une aide dans ce processus (à vrai dire, ça fait une paye que je me dis que je vais me pencher dessus et je ne l'ai que survolé donc je ne sais pas vraiment).
Après, la sécurité, c'est de toujours contraignant et au final, c'est un compromis entre la facilité d'utilisation et la protection que l'on souhaite.
la bonne sécurité, c'est la sécurité pragmatique, qui n'est pas contraignante. Donc elle sera acceptée, utilisée. -- Kevin
Bruno Tréguier
Le 05/03/2011 à 13:19, Nicolas George a écrit :
En revanche, les pilotes et l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce statut ou de l'ignorer.
Jusqu'au jour où ils trouvent comment uploader un nouveau firmware dans le lecteur. C'est un degré de protection, mais pas une protection absolue.
Rien n'est absolu en ce bas monde, mais bon, restons raisonnablement paranoïaques. ;-)
1) je n'ai jamais vu un lecteur de disquette reflashable (ça existe peut-être mais ça doit être bien rare). Ca doit être dû au fait que la gestion "bas niveau" d'un tel média est bien simple par rapport à tout ce qui est venu par la suite (CD, DVD et autres), donc les fonctionnalités supplémentaires à implanter, ou les bugs à corriger, ne doivent pas être légion. Dans le cas d'un floppy, presque tout est fait par le driver (gestion des têtes et tout le reste). Je pense même que dans la majorité des cas, le firmware est carrément en ROM.
2) cette technologie étant désormais obsolète, et n'ayant jamais eutendu parler par le passé d'un virus ayant réussi à franchir cette barrière, je doute que l'avenir voie beaucoup de changements à ce niveau...
Cordialement,
-- Bruno Tréguier
Le 05/03/2011 à 13:19, Nicolas George a écrit :
En revanche, les pilotes et
l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce
statut ou de l'ignorer.
Jusqu'au jour où ils trouvent comment uploader un nouveau firmware dans le
lecteur. C'est un degré de protection, mais pas une protection absolue.
Rien n'est absolu en ce bas monde, mais bon, restons raisonnablement
paranoïaques. ;-)
1) je n'ai jamais vu un lecteur de disquette reflashable (ça existe
peut-être mais ça doit être bien rare). Ca doit être dû au fait que la
gestion "bas niveau" d'un tel média est bien simple par rapport à tout
ce qui est venu par la suite (CD, DVD et autres), donc les
fonctionnalités supplémentaires à implanter, ou les bugs à corriger, ne
doivent pas être légion. Dans le cas d'un floppy, presque tout est fait
par le driver (gestion des têtes et tout le reste). Je pense même que
dans la majorité des cas, le firmware est carrément en ROM.
2) cette technologie étant désormais obsolète, et n'ayant jamais eutendu
parler par le passé d'un virus ayant réussi à franchir cette barrière,
je doute que l'avenir voie beaucoup de changements à ce niveau...
En revanche, les pilotes et l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce statut ou de l'ignorer.
Jusqu'au jour où ils trouvent comment uploader un nouveau firmware dans le lecteur. C'est un degré de protection, mais pas une protection absolue.
Rien n'est absolu en ce bas monde, mais bon, restons raisonnablement paranoïaques. ;-)
1) je n'ai jamais vu un lecteur de disquette reflashable (ça existe peut-être mais ça doit être bien rare). Ca doit être dû au fait que la gestion "bas niveau" d'un tel média est bien simple par rapport à tout ce qui est venu par la suite (CD, DVD et autres), donc les fonctionnalités supplémentaires à implanter, ou les bugs à corriger, ne doivent pas être légion. Dans le cas d'un floppy, presque tout est fait par le driver (gestion des têtes et tout le reste). Je pense même que dans la majorité des cas, le firmware est carrément en ROM.
2) cette technologie étant désormais obsolète, et n'ayant jamais eutendu parler par le passé d'un virus ayant réussi à franchir cette barrière, je doute que l'avenir voie beaucoup de changements à ce niveau...
Cordialement,
-- Bruno Tréguier
Bruno Tréguier
Le 05/03/2011 à 13:44, Yannix a écrit :
Le 05/03/2011 10:01, Nicolas George a écrit :
Yannix , dans le message<iks9db$o2v$, a écrit :
Le truc du login sur une console distante (ou pas) c'est de commencer par taper un faux mot de passe au premier login et voir si il passe...
C'est assez idiot, ce « truc ».
Ah ? Et ben pourquoi ? Le "machin" te demande un mot de passe, tu commences par lui en donner un faux, et si jamais le "machin" te dit "ok" c'est qu'il est compromis. Non ?
Mouais... En même temps, s'il vous répond "mot de passe erroné", est-ce que vous pouvez pour autant en déduire que la machine est saine ? Non...
Vous sous-estimez l'ennemi, là... ;-)
Cordialement,
-- Bruno Tréguier
Le 05/03/2011 à 13:44, Yannix a écrit :
Le 05/03/2011 10:01, Nicolas George a écrit :
Yannix , dans le message<iks9db$o2v$1@speranza.aioe.org>, a écrit :
Le truc du login sur une console distante (ou pas) c'est de commencer
par taper un faux mot de passe au premier login et voir si il passe...
C'est assez idiot, ce « truc ».
Ah ? Et ben pourquoi ? Le "machin" te demande un mot de passe, tu
commences par lui en donner un faux, et si jamais le "machin" te dit
"ok" c'est qu'il est compromis. Non ?
Mouais... En même temps, s'il vous répond "mot de passe erroné", est-ce
que vous pouvez pour autant en déduire que la machine est saine ? Non...
Le truc du login sur une console distante (ou pas) c'est de commencer par taper un faux mot de passe au premier login et voir si il passe...
C'est assez idiot, ce « truc ».
Ah ? Et ben pourquoi ? Le "machin" te demande un mot de passe, tu commences par lui en donner un faux, et si jamais le "machin" te dit "ok" c'est qu'il est compromis. Non ?
Mouais... En même temps, s'il vous répond "mot de passe erroné", est-ce que vous pouvez pour autant en déduire que la machine est saine ? Non...
Vous sous-estimez l'ennemi, là... ;-)
Cordialement,
-- Bruno Tréguier
Fabien LE LEZ
On Sat, 05 Mar 2011 04:07:15 +0100, Yannix :
Le truc du login sur une console distante (ou pas) c'est de commencer par taper un faux mot de passe au premier login et voir si il passe...
Pas bon. Logiquement, pour faire un bon MitM, il faut que le serveur du pirate se connecte au vrai serveur dès qu'il reçoit une connexion. Il peut donc savoir si un mot de passe est correct ou pas. En fait, il transmet toutes les commandes, de façon transparente pour l'utilisateur, et en profite pour intercepter le mot de passe, puis tout ce qui est tapé, y compris le mot de passe root si tu fais un "su".
On Sat, 05 Mar 2011 04:07:15 +0100, Yannix <faitmoipeur@gmail.com>:
Le truc du login sur une console distante (ou pas) c'est de commencer
par taper un faux mot de passe au premier login et voir si il passe...
Pas bon. Logiquement, pour faire un bon MitM, il faut que le serveur
du pirate se connecte au vrai serveur dès qu'il reçoit une connexion.
Il peut donc savoir si un mot de passe est correct ou pas.
En fait, il transmet toutes les commandes, de façon transparente pour
l'utilisateur, et en profite pour intercepter le mot de passe, puis
tout ce qui est tapé, y compris le mot de passe root si tu fais un
"su".
Le truc du login sur une console distante (ou pas) c'est de commencer par taper un faux mot de passe au premier login et voir si il passe...
Pas bon. Logiquement, pour faire un bon MitM, il faut que le serveur du pirate se connecte au vrai serveur dès qu'il reçoit une connexion. Il peut donc savoir si un mot de passe est correct ou pas. En fait, il transmet toutes les commandes, de façon transparente pour l'utilisateur, et en profite pour intercepter le mot de passe, puis tout ce qui est tapé, y compris le mot de passe root si tu fais un "su".
Fabien LE LEZ
On Sat, 05 Mar 2011 13:56:47 +0100, Bruno Tréguier :
1) je n'ai jamais vu un lecteur de disquette reflashable
Faut dire qu'à l'époque où les lecteurs de disquettes ont été conçus, la mémoire Flash n'existait pas.
On Sat, 05 Mar 2011 13:56:47 +0100, Bruno Tréguier
<bruno.treguier_at_shom.fr@nullepart.invalid>:
1) je n'ai jamais vu un lecteur de disquette reflashable
Faut dire qu'à l'époque où les lecteurs de disquettes ont été conçus,
la mémoire Flash n'existait pas.
On Sat, 05 Mar 2011 13:56:47 +0100, Bruno Tréguier :
1) je n'ai jamais vu un lecteur de disquette reflashable
Faut dire qu'à l'époque où les lecteurs de disquettes ont été conçus, la mémoire Flash n'existait pas.
Ok, abus de langage. ;-) Ca pouvait être de l'EEPROM, quoi.
Cordialement,
-- Bruno Tréguier
Benoit Izac
Bonjour,
le 05/03/2011 à 13:44, Kevin Denis a écrit dans le message :
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est contraignant.
Pas plus que si j'utilise une clé de chiffrement stockée sur la clé USB.
Le problème n'est pas la clé de chiffrement, mais le code en clair qui s'éxécute au démarrage et qui peut être modifié par un attaquant.
J'ai bien compris. Ce que je dis c'est que mettre mon /boot sur une clé USB n'est pas plus contraignant que d'utiliser une clé de chiffrement (au lieu d'une paraphrase) stockée sur une clé USB ; dans les deux cas, il faut la clé USB pour démarrer donc la contrainte est la même.
D'ailleurs je me demande si TPM ne pourrait pas apporter une aide dans ce processus (à vrai dire, ça fait une paye que je me dis que je vais me pencher dessus et je ne l'ai que survolé donc je ne sais pas vraiment).
J'ai juste survolé la partie TPM et, si j'ai bien compris, ça permet de contourner le problème (le chiffrement du disque n'est pas une sécurité suffisante) que tu évoques quelques messages plus haut.
Après, la sécurité, c'est de toujours contraignant et au final, c'est un compromis entre la facilité d'utilisation et la protection que l'on souhaite.
la bonne sécurité, c'est la sécurité pragmatique, qui n'est pas contraignante. Donc elle sera acceptée, utilisée.
Je suis pas d'accord. Entre n'avoir aucun mot de passe (c'est le cas pour la plupart des ordinateurs familiaux où la session s'ouvre au démarrage du PC) et avoir un mot de passe d'au moins neuf caractères avec au moins une majuscule, une minuscule, un chiffre et un caractère non alphanumérique, tu reconnaîtras que la contrainte et la sécurité ne sont pas du tout les mêmes dans chacun des cas.
Avoir un disque chiffré pour éviter qu'en cas de vol, le voleur n'ai accès au contenu est forcément contraignant : paraphrase à taper ou clé à fournir au démarrage.
Administration du système : mise à jour des applications, arrêter les services inutiles, analyse des journaux, restriction des utilisateurs, mise en place de quota, tout ceci est contraignant pour la personne qui s'en occupe.
Faire des sauvegardes, c'est aussi une contrainte, il faut changer les supports, les mettre en lieu sûr, etc.
Bref, les exemples ne manquent pas et pourtant la sécurité ça passe forcément par là. Maintenant, si tu connais de la sécurité sans contrainte, j'attends avec impatience des exemples.
-- Benoit Izac
Bonjour,
le 05/03/2011 à 13:44, Kevin Denis a écrit dans le message
<slrnin4fvu.fpd.kevin@slackwall.local.tux> :
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est
contraignant.
Pas plus que si j'utilise une clé de chiffrement stockée sur la clé USB.
Le problème n'est pas la clé de chiffrement, mais le code en clair qui
s'éxécute au démarrage et qui peut être modifié par un attaquant.
J'ai bien compris. Ce que je dis c'est que mettre mon /boot sur une clé
USB n'est pas plus contraignant que d'utiliser une clé de chiffrement
(au lieu d'une paraphrase) stockée sur une clé USB ; dans les deux cas,
il faut la clé USB pour démarrer donc la contrainte est la même.
D'ailleurs je me demande si TPM ne pourrait pas apporter une aide dans
ce processus (à vrai dire, ça fait une paye que je me dis que je vais me
pencher dessus et je ne l'ai que survolé donc je ne sais pas vraiment).
J'ai juste survolé la partie TPM et, si j'ai bien compris, ça permet de
contourner le problème (le chiffrement du disque n'est pas une sécurité
suffisante) que tu évoques quelques messages plus haut.
Après, la sécurité, c'est de toujours contraignant et au final, c'est un
compromis entre la facilité d'utilisation et la protection que l'on
souhaite.
la bonne sécurité, c'est la sécurité pragmatique, qui n'est pas
contraignante. Donc elle sera acceptée, utilisée.
Je suis pas d'accord. Entre n'avoir aucun mot de passe (c'est le cas
pour la plupart des ordinateurs familiaux où la session s'ouvre au
démarrage du PC) et avoir un mot de passe d'au moins neuf caractères
avec au moins une majuscule, une minuscule, un chiffre et un caractère
non alphanumérique, tu reconnaîtras que la contrainte et la sécurité ne
sont pas du tout les mêmes dans chacun des cas.
Avoir un disque chiffré pour éviter qu'en cas de vol, le voleur n'ai
accès au contenu est forcément contraignant : paraphrase à taper ou clé
à fournir au démarrage.
Administration du système : mise à jour des applications, arrêter les
services inutiles, analyse des journaux, restriction des utilisateurs,
mise en place de quota, tout ceci est contraignant pour la personne qui
s'en occupe.
Faire des sauvegardes, c'est aussi une contrainte, il faut changer les
supports, les mettre en lieu sûr, etc.
Bref, les exemples ne manquent pas et pourtant la sécurité ça passe
forcément par là. Maintenant, si tu connais de la sécurité sans
contrainte, j'attends avec impatience des exemples.
le 05/03/2011 à 13:44, Kevin Denis a écrit dans le message :
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est contraignant.
Pas plus que si j'utilise une clé de chiffrement stockée sur la clé USB.
Le problème n'est pas la clé de chiffrement, mais le code en clair qui s'éxécute au démarrage et qui peut être modifié par un attaquant.
J'ai bien compris. Ce que je dis c'est que mettre mon /boot sur une clé USB n'est pas plus contraignant que d'utiliser une clé de chiffrement (au lieu d'une paraphrase) stockée sur une clé USB ; dans les deux cas, il faut la clé USB pour démarrer donc la contrainte est la même.
D'ailleurs je me demande si TPM ne pourrait pas apporter une aide dans ce processus (à vrai dire, ça fait une paye que je me dis que je vais me pencher dessus et je ne l'ai que survolé donc je ne sais pas vraiment).
J'ai juste survolé la partie TPM et, si j'ai bien compris, ça permet de contourner le problème (le chiffrement du disque n'est pas une sécurité suffisante) que tu évoques quelques messages plus haut.
Après, la sécurité, c'est de toujours contraignant et au final, c'est un compromis entre la facilité d'utilisation et la protection que l'on souhaite.
la bonne sécurité, c'est la sécurité pragmatique, qui n'est pas contraignante. Donc elle sera acceptée, utilisée.
Je suis pas d'accord. Entre n'avoir aucun mot de passe (c'est le cas pour la plupart des ordinateurs familiaux où la session s'ouvre au démarrage du PC) et avoir un mot de passe d'au moins neuf caractères avec au moins une majuscule, une minuscule, un chiffre et un caractère non alphanumérique, tu reconnaîtras que la contrainte et la sécurité ne sont pas du tout les mêmes dans chacun des cas.
Avoir un disque chiffré pour éviter qu'en cas de vol, le voleur n'ai accès au contenu est forcément contraignant : paraphrase à taper ou clé à fournir au démarrage.
Administration du système : mise à jour des applications, arrêter les services inutiles, analyse des journaux, restriction des utilisateurs, mise en place de quota, tout ceci est contraignant pour la personne qui s'en occupe.
Faire des sauvegardes, c'est aussi une contrainte, il faut changer les supports, les mettre en lieu sûr, etc.
Bref, les exemples ne manquent pas et pourtant la sécurité ça passe forcément par là. Maintenant, si tu connais de la sécurité sans contrainte, j'attends avec impatience des exemples.
