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... ?
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
Oui, j'avais pensé à cet exemple aussi effectivement. En plus on ne peut pas dire qu'un code de CB réponde (même de loin) à la plus laxiste des politiques de sécurité concernant l'entropie des mots de passe...
Cordialement,
Bruno Tréguier
Par contre la carte se bloque après 3 essais infructueux.
C'est exactement ce qui se passe avec l'os400
-- Pour me répondre, enlever zerospam
Erwan David a exprimé avec précision :
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> écrivait :
Le 02/03/2011 à 23:37, Erwan David a écrit :
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma
nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
Oui, j'avais pensé à cet exemple aussi effectivement. En plus on ne
peut pas dire qu'un code de CB réponde (même de loin) à la plus
laxiste des politiques de sécurité concernant l'entropie des mots de
passe...
Cordialement,
Bruno Tréguier
Par contre la carte se bloque après 3 essais infructueux.
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
Oui, j'avais pensé à cet exemple aussi effectivement. En plus on ne peut pas dire qu'un code de CB réponde (même de loin) à la plus laxiste des politiques de sécurité concernant l'entropie des mots de passe...
Cordialement,
Bruno Tréguier
Par contre la carte se bloque après 3 essais infructueux.
C'est exactement ce qui se passe avec l'os400
-- Pour me répondre, enlever zerospam
Yannix
Le 02/03/2011 23:05, Bruno Tréguier a écrit :
Le 01/03/2011 à 11:47, (Marcus Ramatut) a écrit :
J'ai aussi vu le mot de passe écrit au crayon gris sur le plastique de l'écran cathodique.
Sur le filtre d'écran tu veux dire ?
Non, sur le plastique beige du moniteur.
:-)
Autre endroit de prédilection: le post-it sous le clavier...
Oui, ou dans le tiroir fermé à clé de la secrétaire.
A ce propos (ce qui suit n'est *pas* un troll, c'est sérieux): que pensez-vous des politiques de gestion des mots de passe imposant un changement régulier de ce dernier ?
Exemple dans une boîte sous-traitante d'une grosse bien sécurisée ou je suis passé :
Le type à distance (via un client vpn cisco) sous-traitant de la grosse boite ne pouvait accéder au LAN de la grosse boite que grace à un mot de passe changé tout les mois et un code fourni par la "calculette".
Inutile de vous dire que le type en question, ayant droit à des congés et autres RTT comme tout le monde a de facto transmis 1/ la calculette à son remplaçant temporaire et 2/ la méthode pour retrouver son mot de passe qu'il changeait tout les mois.
X.
Cette pratique est en vogue depuis pas mal de temps, comme nous le savons tous, mais j'ai l'impression que le vent est en train de tourner à ce niveau, et que de plus en plus, on trouve des gens qui osent dire que ce n'est pas forcément une bonne idée, *si* par ailleurs on incite fortement les utilisateurs à utiliser un mot de passe qui tient la route (et qu'on les "éduque" un peu à ce niveau).
Si on examine les choses froidement (et sauf erreur ou oubli de ma part), je vois 6 manières principales d'obtenir un mot de passe de façon frauduleuse:
1) le demander... :-) Un peu d'ingéniérie sociale, et hop, la plupart du temps, ça marche: "oui, bonjour, c'est tartempion, du service informatique... On a un souci avec votre compte et on a besoin de votre mot de passe...". Ca paraît gros, mais ça fonctionne souvent.
2) utiliser un keylogger.
3) utiliser les rayonnements compromettants émis par le clavier (même filaire). Pas simple à réaliser, mais j'ai vu une démo convaincante au SSTIC 2009: http://www.sstic.org/2009/presentation/Emanations_Compromettantes_Electromagnetiques_des_Claviers_Filaires_et_Sans_fil/
4) regarder par dessus l'épaule de la victime au moment où elle tape son mot de passe (nécessite donc la présence physique de l'attaquant).
5) tenter de se loguer de façon répétitive.
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
Dans les cas 1, 2 et 3, il est évident que le fait de changer régulièrement le mot de passe ne servira à rien. Dans le cas 4, si on a un doute sur le fait que quelqu'un ait pu nous espionner, le mot de passe doit être changé *immédiatement*, pas après 3 semaines ou 2 mois. Dans le cas 5, une sécurité de blocage après un certain nombre de tentatives infructueuses peut s'avérer efficace, et dans le cas 6, avec les puissances de calcul disponibles maintenant, en règle générale, un mot de passe est trouvé dans les premières heures de calcul (s'il est faible), ou pas du tout (du moins dans un temps raisonnable).
Au regard de ce qui précède, on peut donc s'interroger sur l'efficacité réelle d'une politique de changement fréquent de mot de passe (avec des raffinements du genre interdiction de réutiliser les x derniers, interdiction de nouveau changement avant un certain temps, distance de hamming minimale avec les x précédents - ce dernier point impliquant d'ailleurs que les mots de passe sont stockés *en clair* quelque part, ce qui n'est pas forcément un bien).
Une telle politique a par ailleurs souvent l'inconvénient d'affaiblir les mots de passe choisis par les utilisateurs (humains, à mémoire forcément limitée et imparfaite), mots de passe qui deviennent donc, de fait, plus vulnérables aux attaques 5 et 6.
Des voix de gens assez connus dans la sécurité commencent d'ailleurs à s'élever pour aller dans ce sens, comme celle de Bruce Schneier (rien que ça): http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
J'ai également trouvé d'autres articles, dont l'un est d'ailleurs cité par Schneier lui-même: http://www.cs.unc.edu/~yinqian/papers/PasswordExpire.pdf
Même Microsoft dit la même chose (bon, ok, ça ce n'est pas un argument ;-) ): http://www.pcmag.com/article2/0,2817,2362692,00.asp
Alors, évidemment, tout ce qui précède doit être modulé en fonction de l'importance des données à protéger dans le compte ou l'application protégée par un mot de passe, mais dans beaucoup de cas, il semble que les inconvénients apportés par une politique de changement fréquent de mot de passe sont de plus en plus considérés comme étant plus importants que les avantages... En d'autres termes: le mieux est l'ennemi du bien.
A titre personnel, je suis tout à fait en phase avec cette analyse des choses, à la condition expresse que, comme je le précisais au départ, l'on incite effectivement les utilisateurs à employer des mots de passe "forts", présentant des garanties minimales d'entropie. L'utilisation, en interne à l'entreprise, d'outils de crackage de mots de passe et de rainbow tables peut d'ailleurs améliorer grandement la situation: mot de passe trouvé = compte bloqué. Hop ! :-)
Des avis ?
Bonne soirée...
Cordialement,
Bruno Tréguier
Le 02/03/2011 23:05, Bruno Tréguier a écrit :
Le 01/03/2011 à 11:47, Ramus.rayar@club-internet.fr (Marcus Ramatut) a
écrit :
J'ai aussi vu le mot de passe écrit au crayon gris sur le plastique de
l'écran cathodique.
Sur le filtre d'écran tu veux dire ?
Non, sur le plastique beige du moniteur.
:-)
Autre endroit de prédilection: le post-it sous le clavier...
Oui, ou dans le tiroir fermé à clé de la secrétaire.
A ce propos (ce qui suit n'est *pas* un troll, c'est sérieux): que
pensez-vous des politiques de gestion des mots de passe imposant un
changement régulier de ce dernier ?
Exemple dans une boîte sous-traitante d'une grosse bien sécurisée ou je
suis passé :
Le type à distance (via un client vpn cisco) sous-traitant de la grosse
boite ne pouvait accéder au LAN de la grosse boite que grace à un mot de
passe changé tout les mois et un code fourni par la "calculette".
Inutile de vous dire que le type en question, ayant droit à des congés
et autres RTT comme tout le monde a de facto transmis 1/ la calculette à
son remplaçant temporaire et 2/ la méthode pour retrouver son mot de
passe qu'il changeait tout les mois.
X.
Cette pratique est en vogue depuis pas mal de temps, comme nous le
savons tous, mais j'ai l'impression que le vent est en train de tourner
à ce niveau, et que de plus en plus, on trouve des gens qui osent dire
que ce n'est pas forcément une bonne idée, *si* par ailleurs on incite
fortement les utilisateurs à utiliser un mot de passe qui tient la route
(et qu'on les "éduque" un peu à ce niveau).
Si on examine les choses froidement (et sauf erreur ou oubli de ma
part), je vois 6 manières principales d'obtenir un mot de passe de façon
frauduleuse:
1) le demander... :-) Un peu d'ingéniérie sociale, et hop, la plupart du
temps, ça marche: "oui, bonjour, c'est tartempion, du service
informatique... On a un souci avec votre compte et on a besoin de votre
mot de passe...". Ca paraît gros, mais ça fonctionne souvent.
2) utiliser un keylogger.
3) utiliser les rayonnements compromettants émis par le clavier (même
filaire). Pas simple à réaliser, mais j'ai vu une démo convaincante au
SSTIC 2009:
http://www.sstic.org/2009/presentation/Emanations_Compromettantes_Electromagnetiques_des_Claviers_Filaires_et_Sans_fil/
4) regarder par dessus l'épaule de la victime au moment où elle tape son
mot de passe (nécessite donc la présence physique de l'attaquant).
5) tenter de se loguer de façon répétitive.
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker
"offline".
Dans les cas 1, 2 et 3, il est évident que le fait de changer
régulièrement le mot de passe ne servira à rien. Dans le cas 4, si on a
un doute sur le fait que quelqu'un ait pu nous espionner, le mot de
passe doit être changé *immédiatement*, pas après 3 semaines ou 2 mois.
Dans le cas 5, une sécurité de blocage après un certain nombre de
tentatives infructueuses peut s'avérer efficace, et dans le cas 6, avec
les puissances de calcul disponibles maintenant, en règle générale, un
mot de passe est trouvé dans les premières heures de calcul (s'il est
faible), ou pas du tout (du moins dans un temps raisonnable).
Au regard de ce qui précède, on peut donc s'interroger sur l'efficacité
réelle d'une politique de changement fréquent de mot de passe (avec des
raffinements du genre interdiction de réutiliser les x derniers,
interdiction de nouveau changement avant un certain temps, distance de
hamming minimale avec les x précédents - ce dernier point impliquant
d'ailleurs que les mots de passe sont stockés *en clair* quelque part,
ce qui n'est pas forcément un bien).
Une telle politique a par ailleurs souvent l'inconvénient d'affaiblir
les mots de passe choisis par les utilisateurs (humains, à mémoire
forcément limitée et imparfaite), mots de passe qui deviennent donc, de
fait, plus vulnérables aux attaques 5 et 6.
Des voix de gens assez connus dans la sécurité commencent d'ailleurs à
s'élever pour aller dans ce sens, comme celle de Bruce Schneier (rien
que ça): http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
J'ai également trouvé d'autres articles, dont l'un est d'ailleurs cité
par Schneier lui-même:
http://www.cs.unc.edu/~yinqian/papers/PasswordExpire.pdf
Même Microsoft dit la même chose (bon, ok, ça ce n'est pas un argument
;-) ): http://www.pcmag.com/article2/0,2817,2362692,00.asp
Alors, évidemment, tout ce qui précède doit être modulé en fonction de
l'importance des données à protéger dans le compte ou l'application
protégée par un mot de passe, mais dans beaucoup de cas, il semble que
les inconvénients apportés par une politique de changement fréquent de
mot de passe sont de plus en plus considérés comme étant plus importants
que les avantages... En d'autres termes: le mieux est l'ennemi du bien.
A titre personnel, je suis tout à fait en phase avec cette analyse des
choses, à la condition expresse que, comme je le précisais au départ,
l'on incite effectivement les utilisateurs à employer des mots de passe
"forts", présentant des garanties minimales d'entropie. L'utilisation,
en interne à l'entreprise, d'outils de crackage de mots de passe et de
rainbow tables peut d'ailleurs améliorer grandement la situation: mot de
passe trouvé = compte bloqué. Hop ! :-)
J'ai aussi vu le mot de passe écrit au crayon gris sur le plastique de l'écran cathodique.
Sur le filtre d'écran tu veux dire ?
Non, sur le plastique beige du moniteur.
:-)
Autre endroit de prédilection: le post-it sous le clavier...
Oui, ou dans le tiroir fermé à clé de la secrétaire.
A ce propos (ce qui suit n'est *pas* un troll, c'est sérieux): que pensez-vous des politiques de gestion des mots de passe imposant un changement régulier de ce dernier ?
Exemple dans une boîte sous-traitante d'une grosse bien sécurisée ou je suis passé :
Le type à distance (via un client vpn cisco) sous-traitant de la grosse boite ne pouvait accéder au LAN de la grosse boite que grace à un mot de passe changé tout les mois et un code fourni par la "calculette".
Inutile de vous dire que le type en question, ayant droit à des congés et autres RTT comme tout le monde a de facto transmis 1/ la calculette à son remplaçant temporaire et 2/ la méthode pour retrouver son mot de passe qu'il changeait tout les mois.
X.
Cette pratique est en vogue depuis pas mal de temps, comme nous le savons tous, mais j'ai l'impression que le vent est en train de tourner à ce niveau, et que de plus en plus, on trouve des gens qui osent dire que ce n'est pas forcément une bonne idée, *si* par ailleurs on incite fortement les utilisateurs à utiliser un mot de passe qui tient la route (et qu'on les "éduque" un peu à ce niveau).
Si on examine les choses froidement (et sauf erreur ou oubli de ma part), je vois 6 manières principales d'obtenir un mot de passe de façon frauduleuse:
1) le demander... :-) Un peu d'ingéniérie sociale, et hop, la plupart du temps, ça marche: "oui, bonjour, c'est tartempion, du service informatique... On a un souci avec votre compte et on a besoin de votre mot de passe...". Ca paraît gros, mais ça fonctionne souvent.
2) utiliser un keylogger.
3) utiliser les rayonnements compromettants émis par le clavier (même filaire). Pas simple à réaliser, mais j'ai vu une démo convaincante au SSTIC 2009: http://www.sstic.org/2009/presentation/Emanations_Compromettantes_Electromagnetiques_des_Claviers_Filaires_et_Sans_fil/
4) regarder par dessus l'épaule de la victime au moment où elle tape son mot de passe (nécessite donc la présence physique de l'attaquant).
5) tenter de se loguer de façon répétitive.
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
Dans les cas 1, 2 et 3, il est évident que le fait de changer régulièrement le mot de passe ne servira à rien. Dans le cas 4, si on a un doute sur le fait que quelqu'un ait pu nous espionner, le mot de passe doit être changé *immédiatement*, pas après 3 semaines ou 2 mois. Dans le cas 5, une sécurité de blocage après un certain nombre de tentatives infructueuses peut s'avérer efficace, et dans le cas 6, avec les puissances de calcul disponibles maintenant, en règle générale, un mot de passe est trouvé dans les premières heures de calcul (s'il est faible), ou pas du tout (du moins dans un temps raisonnable).
Au regard de ce qui précède, on peut donc s'interroger sur l'efficacité réelle d'une politique de changement fréquent de mot de passe (avec des raffinements du genre interdiction de réutiliser les x derniers, interdiction de nouveau changement avant un certain temps, distance de hamming minimale avec les x précédents - ce dernier point impliquant d'ailleurs que les mots de passe sont stockés *en clair* quelque part, ce qui n'est pas forcément un bien).
Une telle politique a par ailleurs souvent l'inconvénient d'affaiblir les mots de passe choisis par les utilisateurs (humains, à mémoire forcément limitée et imparfaite), mots de passe qui deviennent donc, de fait, plus vulnérables aux attaques 5 et 6.
Des voix de gens assez connus dans la sécurité commencent d'ailleurs à s'élever pour aller dans ce sens, comme celle de Bruce Schneier (rien que ça): http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
J'ai également trouvé d'autres articles, dont l'un est d'ailleurs cité par Schneier lui-même: http://www.cs.unc.edu/~yinqian/papers/PasswordExpire.pdf
Même Microsoft dit la même chose (bon, ok, ça ce n'est pas un argument ;-) ): http://www.pcmag.com/article2/0,2817,2362692,00.asp
Alors, évidemment, tout ce qui précède doit être modulé en fonction de l'importance des données à protéger dans le compte ou l'application protégée par un mot de passe, mais dans beaucoup de cas, il semble que les inconvénients apportés par une politique de changement fréquent de mot de passe sont de plus en plus considérés comme étant plus importants que les avantages... En d'autres termes: le mieux est l'ennemi du bien.
A titre personnel, je suis tout à fait en phase avec cette analyse des choses, à la condition expresse que, comme je le précisais au départ, l'on incite effectivement les utilisateurs à employer des mots de passe "forts", présentant des garanties minimales d'entropie. L'utilisation, en interne à l'entreprise, d'outils de crackage de mots de passe et de rainbow tables peut d'ailleurs améliorer grandement la situation: mot de passe trouvé = compte bloqué. Hop ! :-)
Des avis ?
Bonne soirée...
Cordialement,
Bruno Tréguier
Yannix
Le 04/03/2011 16:52, Nicolas George a écrit :
Stephane Catteau , dans le message , a écrit :
A moi ça me semble évident. L'on ne doit pas se connecter à l'ordinateur en face de soit avec le compte administrateur[1], non par mesure de sécurité mais pour éviter de faire des conneries. Je ne vois pas pourquoi cela différent au motif que l'ordinateur est distant.
Parce que quand l'ordinateur est distant, ce que tu lances avec les droits du compte où tu te connectes, c'est un shell, exactement comme si tu utilies su, alors que quand l'ordinateur est local, de nos jours, ce que tu lances, c'est une interface graphique mal fichue.
Il n'y a pas plus d'objection à se loguer root sur une console texte qu'en utilisant su.
Oui mais bon, il s'imagine beaucoup de chose le Catteau...
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...
X.
Le 04/03/2011 16:52, Nicolas George a écrit :
Stephane Catteau , dans le message <mn.22e07db38b636997.30736@sc4x.org>,
a écrit :
A moi ça me semble évident. L'on ne doit pas se connecter à
l'ordinateur en face de soit avec le compte administrateur[1], non par
mesure de sécurité mais pour éviter de faire des conneries. Je ne vois
pas pourquoi cela différent au motif que l'ordinateur est distant.
Parce que quand l'ordinateur est distant, ce que tu lances avec les droits
du compte où tu te connectes, c'est un shell, exactement comme si tu utilies
su, alors que quand l'ordinateur est local, de nos jours, ce que tu lances,
c'est une interface graphique mal fichue.
Il n'y a pas plus d'objection à se loguer root sur une console texte qu'en
utilisant su.
Oui mais bon, il s'imagine beaucoup de chose le Catteau...
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...
A moi ça me semble évident. L'on ne doit pas se connecter à l'ordinateur en face de soit avec le compte administrateur[1], non par mesure de sécurité mais pour éviter de faire des conneries. Je ne vois pas pourquoi cela différent au motif que l'ordinateur est distant.
Parce que quand l'ordinateur est distant, ce que tu lances avec les droits du compte où tu te connectes, c'est un shell, exactement comme si tu utilies su, alors que quand l'ordinateur est local, de nos jours, ce que tu lances, c'est une interface graphique mal fichue.
Il n'y a pas plus d'objection à se loguer root sur une console texte qu'en utilisant su.
Oui mais bon, il s'imagine beaucoup de chose le Catteau...
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...
X.
Fabien LE LEZ
On 04 Mar 2011 15:54:42 GMT, Nicolas George <nicolas$:
Et bonjour le keylogger dans l'ordi vérolé.
Certes. Mais...
Une clef USB, ça coûte presque rien ete c'est bien pratique de temps en temps.
une clé USB a exactement le même problème : si tu la mets dans un PC vérolé, son contenu est compromis.
On 04 Mar 2011 15:54:42 GMT, Nicolas George
<nicolas$george@salle-s.org>:
Et bonjour le keylogger dans l'ordi vérolé.
Certes. Mais...
Une clef USB, ça coûte presque rien ete c'est bien pratique de temps en
temps.
une clé USB a exactement le même problème : si tu la mets dans un PC
vérolé, son contenu est compromis.
| > Une clef USB, ça coûte presque rien ete c'est bien pratique de | > temps en temps.
| une clé USB a exactement le même problème : si tu la mets dans | un PC vérolé, son contenu est compromis.
Exact et je ne comprends pas qu'il n'y ait pas de contact physique pour empêcher l'écriture comme il y avait sur les disquettes à l'époque héroïque.
Mais ça doit être trop simple comme solution. Ou trop "cher" :-)
--
Nicolas George
Fabien LE LEZ , dans le message , a écrit :
une clé USB a exactement le même problème : si tu la mets dans un PC vérolé, son contenu est compromis.
C'est vrai, mais entre un kelogger qui garde trace de tout ce qu'il voit sans discernement et un truc capable de choper une clef déchiffrée dans la mémoire d'un ssh-agent, il y a quand même un gouffre.
Fabien LE LEZ , dans le message
<61i3n6p30vi36stds5g5ocqfsvk99vaids@4ax.com>, a écrit :
une clé USB a exactement le même problème : si tu la mets dans un PC
vérolé, son contenu est compromis.
C'est vrai, mais entre un kelogger qui garde trace de tout ce qu'il voit
sans discernement et un truc capable de choper une clef déchiffrée dans la
mémoire d'un ssh-agent, il y a quand même un gouffre.
une clé USB a exactement le même problème : si tu la mets dans un PC vérolé, son contenu est compromis.
C'est vrai, mais entre un kelogger qui garde trace de tout ce qu'il voit sans discernement et un truc capable de choper une clef déchiffrée dans la mémoire d'un ssh-agent, il y a quand même un gouffre.
Nicolas George
Pas de From . , dans le message , a écrit :
Exact et je ne comprends pas qu'il n'y ait pas de contact physique pour empêcher l'écriture comme il y avait sur les disquettes à l'époque héroïque.
Il y a sur les cartes SD, et j'ai déjà vu des clefs USB (vieilles) en avoir.
Mais pour autant, c'est un commutateur physique, mais son fonctionnement est logiciel, que ce soit pour les disquettes ou pour les clef USB.
Pas de From .
, dans le message
<fr.comp.securite.ikss06.2qs.1@2011.hfbc8021a.0503082000>, a écrit :
Exact et je ne comprends pas qu'il n'y ait pas de contact physique
pour empêcher l'écriture comme il y avait sur les disquettes à
l'époque héroïque.
Il y a sur les cartes SD, et j'ai déjà vu des clefs USB (vieilles) en avoir.
Mais pour autant, c'est un commutateur physique, mais son fonctionnement est
logiciel, que ce soit pour les disquettes ou pour les clef USB.
Exact et je ne comprends pas qu'il n'y ait pas de contact physique pour empêcher l'écriture comme il y avait sur les disquettes à l'époque héroïque.
Mais ça doit être trop simple comme solution. Ou trop "cher" :-)
Si, ça existe, mais c'est plus cher, et parfois pas très solide mécaniquement au niveau de l'interrupteur.
Et puis, dans le cas dont on cause, c'est mettre dans une machine vérolée des données privées contenue par la clef.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Bruno Tréguier
Le 05/03/2011 à 9:59, Nicolas George a écrit :
Pas de From . , dans le message , a écrit :
Exact et je ne comprends pas qu'il n'y ait pas de contact physique pour empêcher l'écriture comme il y avait sur les disquettes à l'époque héroïque.
Il y a sur les cartes SD, et j'ai déjà vu des clefs USB (vieilles) en avoir.
Mais pour autant, c'est un commutateur physique, mais son fonctionnement est logiciel, que ce soit pour les disquettes ou pour les clef USB.
Bonjour,
Pour les clefs USB vous avez probablement raison, mais en ce qui concerne les disquettes "de l'époque héroïque" (3 pouces 1/2, 5 pouces 1/4, et pour les plus "décrépits" d'entre nous - dont ma pomme - 8 pouces), 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. En revanche, les pilotes et l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce statut ou de l'ignorer. Un virus, par exemple, n'a aucune possibilité (malgré les nombreuses légendes urbaines qui courent à ce propos) de déverrouiller la protection en écriture d'une disquette...
Cordialement,
-- Bruno Tréguier
Le 05/03/2011 à 9:59, Nicolas George a écrit :
Pas de From .
, dans le message
<fr.comp.securite.ikss06.2qs.1@2011.hfbc8021a.0503082000>, a écrit :
Exact et je ne comprends pas qu'il n'y ait pas de contact physique
pour empêcher l'écriture comme il y avait sur les disquettes à
l'époque héroïque.
Il y a sur les cartes SD, et j'ai déjà vu des clefs USB (vieilles) en avoir.
Mais pour autant, c'est un commutateur physique, mais son fonctionnement est
logiciel, que ce soit pour les disquettes ou pour les clef USB.
Bonjour,
Pour les clefs USB vous avez probablement raison, mais en ce qui
concerne les disquettes "de l'époque héroïque" (3 pouces 1/2, 5 pouces
1/4, et pour les plus "décrépits" d'entre nous - dont ma pomme - 8
pouces), 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. En revanche, les pilotes et
l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce
statut ou de l'ignorer. Un virus, par exemple, n'a aucune possibilité
(malgré les nombreuses légendes urbaines qui courent à ce propos) de
déverrouiller la protection en écriture d'une disquette...
Exact et je ne comprends pas qu'il n'y ait pas de contact physique pour empêcher l'écriture comme il y avait sur les disquettes à l'époque héroïque.
Il y a sur les cartes SD, et j'ai déjà vu des clefs USB (vieilles) en avoir.
Mais pour autant, c'est un commutateur physique, mais son fonctionnement est logiciel, que ce soit pour les disquettes ou pour les clef USB.
Bonjour,
Pour les clefs USB vous avez probablement raison, mais en ce qui concerne les disquettes "de l'époque héroïque" (3 pouces 1/2, 5 pouces 1/4, et pour les plus "décrépits" d'entre nous - dont ma pomme - 8 pouces), 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. En revanche, les pilotes et l'OS, quels qu'ils soient, n'ont pas la possibilité de modifier ce statut ou de l'ignorer. Un virus, par exemple, n'a aucune possibilité (malgré les nombreuses légendes urbaines qui courent à ce propos) de déverrouiller la protection en écriture d'une disquette...
