sécurité des mots de passe

Kevin Denis

05/03/2011 à 17:34

Le 05-03-2011, Benoit Izac a écrit :

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.

ok

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).

<pub gratuite>
http://2010.rmll.info/IMG/pdf/06_denis_article-2.pdf
</pub>

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.

La faiblesse du chiffrement de disque, c'est ce qui reste en clair.
Le TPM te permet de valider le fait que ni ton bootloader, ni
ton noyau, ni ton initrd n'ont été modifié entre deux démarrages.
C'est une caractéristique intéressante.

Administration du système

en dehors de l'horizon de l'utilisateur.

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.

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].
Le WPA en lieu et place de WEP. Le DEP ou l'ALSR. La segmentation
de la mémoire. Tout ça c'est invisible pour l'utilisateur; au final,
c'est de la sécurité. Bitlocker, c'est très bien: le disque est
chiffré sans mot de passe! L'utilisateur lance le système, et
il démarre sans rien demander a l'utilisateur. Taper ssh au
lieu de telnet.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

[1]https a plein de problèmes, je sais, néanmoins c'est employé
et cela remplit parfaitement un de ses rôles: que l'écoute passive
soit impossible.
--
Kevin

Le 05-03-2011, Benoit Izac <use.reply.to@INVALID.ADDRESS> a écrit :

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.

ok

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).

<pub gratuite>
http://2010.rmll.info/IMG/pdf/06_denis_article-2.pdf
</pub>

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.

La faiblesse du chiffrement de disque, c'est ce qui reste en clair.
Le TPM te permet de valider le fait que ni ton bootloader, ni
ton noyau, ni ton initrd n'ont été modifié entre deux démarrages.
C'est une caractéristique intéressante.

Administration du système

en dehors de l'horizon de l'utilisateur.

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.

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].
Le WPA en lieu et place de WEP. Le DEP ou l'ALSR. La segmentation
de la mémoire. Tout ça c'est invisible pour l'utilisateur; au final,
c'est de la sécurité. Bitlocker, c'est très bien: le disque est
chiffré sans mot de passe! L'utilisateur lance le système, et
il démarre sans rien demander a l'utilisateur. Taper ssh au
lieu de telnet.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

[1]https a plein de problèmes, je sais, néanmoins c'est employé
et cela remplit parfaitement un de ses rôles: que l'écoute passive
soit impossible.
--
Kevin

Vous avez filtré cet utilisateur ! Consultez son message

Le 05-03-2011, Benoit Izac a écrit :

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.

ok

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).

<pub gratuite>
http://2010.rmll.info/IMG/pdf/06_denis_article-2.pdf
</pub>

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.

La faiblesse du chiffrement de disque, c'est ce qui reste en clair.
Le TPM te permet de valider le fait que ni ton bootloader, ni
ton noyau, ni ton initrd n'ont été modifié entre deux démarrages.
C'est une caractéristique intéressante.

Administration du système

en dehors de l'horizon de l'utilisateur.

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.

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].
Le WPA en lieu et place de WEP. Le DEP ou l'ALSR. La segmentation
de la mémoire. Tout ça c'est invisible pour l'utilisateur; au final,
c'est de la sécurité. Bitlocker, c'est très bien: le disque est
chiffré sans mot de passe! L'utilisateur lance le système, et
il démarre sans rien demander a l'utilisateur. Taper ssh au
lieu de telnet.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

[1]https a plein de problèmes, je sais, néanmoins c'est employé
et cela remplit parfaitement un de ses rôles: que l'écoute passive
soit impossible.
--
Kevin

Benoit Izac

05/03/2011 à 18:17

Bonjour,

le 05/03/2011 à 17:34, Kevin Denis a écrit dans le message
:

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.

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Heu.. oui et non. Un exemple, ma boite à mis en place depuis peu un
webmail accessible en https, or il se trouve que le certificat n'est pas
signé par une des autorités qui est installé chez le client où je
travaille actuellement. Résultat, à chaque fois que je me connecte, j'ai
le droit à un beau message et une belle couleur rouge à coté de la barre
d'adresse. Autre chose, comme l'utilisateur ne sait pas que ça existe,
il va même pas regarder si c'est chiffré ou non et va envoyer son mot de
passe (ou pire). Donc au final, sans éduquer l'utilisateur (lui
apprendre à vérifier qu'il est bien en https au minimum), ça vaut pas
grand chose.

Le WPA en lieu et place de WEP.

Tiens, justement, combien de temps a-t-il fallu attendre avant que WPA
soit implémenté dans OpenBSD ? Je peux te dire que se fut pour moi
réellement contraignant. De plus, chez moi la clé est un truc de 63
caractères générés aléatoirement, autant dire que sans une clé USB pour
faire un copier/coller, bon courage pour s'authentifier.

Le DEP

Je connais pas mais le premier lien google me dis :
| Des programmes tout à fait corrects peuvent donc être stoppés, rendant
| leur exécution impossible. Cette fonctionnalité provoque parfois au
| démarrage le message suivant: "Pour aider à protéger votre ordinateur,
| Windows à fermer le programme suivant".

ou l'ALSR. La segmentation de la mémoire. Tout ça c'est
invisible pour l'utilisateur; au final, c'est de la sécurité.

Effectivement, tu as raison (ce n'est pas ce que j'ai en tête lorsque je
parle de sécurité pour l'utilisateur final). D'un autre coté, c'est un
peu comme si on parle d'un composant d'une serrure qui permet de
retarder son ouverture alors que la fenêtre d'à coté est grande ouverte.

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Taper ssh au lieu de telnet.

Mais sur une machine Windows, ça demande d'installer/avoir putty.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

Justement, pour en revenir au sujet du thread, je vois pas comment on
peu avoir une authentification par mot de passe sécurisée sans avoir un
mot de passe un minimum complexe. C'est une contrainte et je n'ai pas vu
de solution à ce problème (ou j'ai mal lu).

--
Benoit Izac

Bonjour,

le 05/03/2011 à 17:34, Kevin Denis a écrit dans le message
<slrnin4tek.fr8.kevin@slackwall.local.tux> :

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.

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Heu.. oui et non. Un exemple, ma boite à mis en place depuis peu un
webmail accessible en https, or il se trouve que le certificat n'est pas
signé par une des autorités qui est installé chez le client où je
travaille actuellement. Résultat, à chaque fois que je me connecte, j'ai
le droit à un beau message et une belle couleur rouge à coté de la barre
d'adresse. Autre chose, comme l'utilisateur ne sait pas que ça existe,
il va même pas regarder si c'est chiffré ou non et va envoyer son mot de
passe (ou pire). Donc au final, sans éduquer l'utilisateur (lui
apprendre à vérifier qu'il est bien en https au minimum), ça vaut pas
grand chose.

Le WPA en lieu et place de WEP.

Tiens, justement, combien de temps a-t-il fallu attendre avant que WPA
soit implémenté dans OpenBSD ? Je peux te dire que se fut pour moi
réellement contraignant. De plus, chez moi la clé est un truc de 63
caractères générés aléatoirement, autant dire que sans une clé USB pour
faire un copier/coller, bon courage pour s'authentifier.

Le DEP

Je connais pas mais le premier lien google me dis :
| Des programmes tout à fait corrects peuvent donc être stoppés, rendant
| leur exécution impossible. Cette fonctionnalité provoque parfois au
| démarrage le message suivant: "Pour aider à protéger votre ordinateur,
| Windows à fermer le programme suivant".

ou l'ALSR. La segmentation de la mémoire. Tout ça c'est
invisible pour l'utilisateur; au final, c'est de la sécurité.

Effectivement, tu as raison (ce n'est pas ce que j'ai en tête lorsque je
parle de sécurité pour l'utilisateur final). D'un autre coté, c'est un
peu comme si on parle d'un composant d'une serrure qui permet de
retarder son ouverture alors que la fenêtre d'à coté est grande ouverte.

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Taper ssh au lieu de telnet.

Mais sur une machine Windows, ça demande d'installer/avoir putty.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

Justement, pour en revenir au sujet du thread, je vois pas comment on
peu avoir une authentification par mot de passe sécurisée sans avoir un
mot de passe un minimum complexe. C'est une contrainte et je n'ai pas vu
de solution à ce problème (ou j'ai mal lu).

--
Benoit Izac

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

le 05/03/2011 à 17:34, Kevin Denis a écrit dans le message
:

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.

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Heu.. oui et non. Un exemple, ma boite à mis en place depuis peu un
webmail accessible en https, or il se trouve que le certificat n'est pas
signé par une des autorités qui est installé chez le client où je
travaille actuellement. Résultat, à chaque fois que je me connecte, j'ai
le droit à un beau message et une belle couleur rouge à coté de la barre
d'adresse. Autre chose, comme l'utilisateur ne sait pas que ça existe,
il va même pas regarder si c'est chiffré ou non et va envoyer son mot de
passe (ou pire). Donc au final, sans éduquer l'utilisateur (lui
apprendre à vérifier qu'il est bien en https au minimum), ça vaut pas
grand chose.

Le WPA en lieu et place de WEP.

Tiens, justement, combien de temps a-t-il fallu attendre avant que WPA
soit implémenté dans OpenBSD ? Je peux te dire que se fut pour moi
réellement contraignant. De plus, chez moi la clé est un truc de 63
caractères générés aléatoirement, autant dire que sans une clé USB pour
faire un copier/coller, bon courage pour s'authentifier.

Le DEP

Je connais pas mais le premier lien google me dis :
| Des programmes tout à fait corrects peuvent donc être stoppés, rendant
| leur exécution impossible. Cette fonctionnalité provoque parfois au
| démarrage le message suivant: "Pour aider à protéger votre ordinateur,
| Windows à fermer le programme suivant".

ou l'ALSR. La segmentation de la mémoire. Tout ça c'est
invisible pour l'utilisateur; au final, c'est de la sécurité.

Effectivement, tu as raison (ce n'est pas ce que j'ai en tête lorsque je
parle de sécurité pour l'utilisateur final). D'un autre coté, c'est un
peu comme si on parle d'un composant d'une serrure qui permet de
retarder son ouverture alors que la fenêtre d'à coté est grande ouverte.

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Taper ssh au lieu de telnet.

Mais sur une machine Windows, ça demande d'installer/avoir putty.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

Justement, pour en revenir au sujet du thread, je vois pas comment on
peu avoir une authentification par mot de passe sécurisée sans avoir un
mot de passe un minimum complexe. C'est une contrainte et je n'ai pas vu
de solution à ce problème (ou j'ai mal lu).

--
Benoit Izac

Ascadix

05/03/2011 à 19:04

Baton Rouge a exprimé avec précision :

On Mon, 28 Feb 2011 18:05:44 +0100, Yannix
wrote:

Ménonkilékon.

Ménonjesuipakon. Je te parie même que la secrétaire connait le mot de
passe de son patron... Du coup, le "taux de réussite" doit être de 5
minutes maxi. ;-)

Elle doit l'avoir sur le bout de la langue ;o))

Celui qui dit que c'est trop court là, il va avoir des ennuis :-p

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Nicolas George

06/03/2011 à 01:24

Kevin Denis , dans le message
, a écrit :

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Comment peut-on écrire des âneries pareilles et prétendre publier des
articles sur la sécurité informatique ?

Fabien LE LEZ

06/03/2011 à 07:00

On Sat, 05 Mar 2011 14:29:08 +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.

Justement, de l'EEPROM, ça ne s'efface pas comme ça, d'un coup de
baguette magique. Si mes souvenirs sont bons, il faut lui balancer du
24 volts dans les dents. Du coup, remplacer le contenu d'une EEPROM
par logiciel, je ne suis pas sûr que ça se fasse.

Kevin Denis

06/03/2011 à 20:03

Le 05-03-2011, Benoit Izac a écrit :

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Heu.. oui et non. Un exemple, ma boite à mis en place depuis peu un
webmail accessible en https, or il se trouve que le certificat n'est pas
signé par une des autorités qui est installé chez le client où je
travaille actuellement. Résultat, à chaque fois que je me connecte, j'ai
le droit à un beau message et une belle couleur rouge à coté de la barre
d'adresse.

Moui, enfin l'admin à le choix, soit de se faire certifier par une
autorité présente dans le magasin par défaut, soit d'ajouter la sienne
dans ton navigateur...

Le WPA en lieu et place de WEP.

Tiens, justement, combien de temps a-t-il fallu attendre avant que WPA
soit implémenté dans OpenBSD ? Je peux te dire que se fut pour moi
réellement contraignant.

La réponse a longtemps été ipsec chez eux. Ils n'ont pas tort. ipsec
sur du wifi, c'est sécurisé.

Le DEP

Je connais pas mais le premier lien google me dis :

Data Execution Prevention. Un truc de codeurs sous windows.
Sous OpenBSD c'est W^X.

ou l'ALSR. La segmentation de la mémoire. Tout ça c'est
invisible pour l'utilisateur; au final, c'est de la sécurité.

Effectivement, tu as raison (ce n'est pas ce que j'ai en tête lorsque je
parle de sécurité pour l'utilisateur final). D'un autre coté, c'est un
peu comme si on parle d'un composant d'une serrure qui permet de
retarder son ouverture alors que la fenêtre d'à coté est grande ouverte.

Oui, enfin, je parlais de sécurité "qui marche". Ca, ça marche. On pourrait
encore citer pleins de trucs. Le fichier shadow. Le sel+hash pour
stocker les mots de passe. C'est bien. Pris seul, ça ne résoud rien,
mais l'ensemble permet d'avoir un système un peu mieux sécurisé.

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Contraintes? D'avoir une puce TPM? (le mode clé USB n'amène rien). Tu
achètes une machine avec TPM, tu la donnes à un youser de base, et
tu gagnes en sécurité: le disque est chiffré, garantie de confidentialité
en cas de perte ou vol et il n'y a pas de mot de passe, le youseur ne se
rend compte de rien et ne risque pas d'oublier son mot passe ou de le
mettre sur un postit puisqu'il n'en a pas.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

Justement, pour en revenir au sujet du thread, je vois pas comment on
peu avoir une authentification par mot de passe sécurisée sans avoir un
mot de passe un minimum complexe. C'est une contrainte et je n'ai pas vu
de solution à ce problème (ou j'ai mal lu).

Carte à puce. En plus, l'"éducation" (mais je n'aime pas ce mot) des
utilisateurs est rapide: il suffit de dire que c'est comme une carte
bleue et que cela demande un PIN. Couplé à un SSO, on résoud d'un
coup tous ces ennuis de mots de passes.
Je connais quelqu'un qui doit entrer un mot de passe différent par
appli web auquel il se connecte dans sa boite. Et là, on tombe sur
des politiques de sécurité de grand n'importe quoi avec des changements
de mdp ineptes comme on parlait plus haut.. (et lors de l'arrivée dans
la boite tous les mots de passe dérivent du nom et prénom du youseur
avec un tout petit variant; autant dire qu'il est possible de toujours
trouver une appli sur laquelle on peut se logger car l'user n'est pas
allé changer son mot de passe sur celle-ci...)

Pour la complexité des "mots de passe" le lien que j'ai fourni plus
haut sur une conférence du SSTIC montre qu'aujourd'hui sous windows,
le mot de passe Bonjour123 est aussi sécurisé que l33t_H4x0R!, donc
le "minimum complexe" reste très raisonnable. Ca doit être le cas
sous linux aussi.
--
Kevin

Le 05-03-2011, Benoit Izac <use.reply.to@INVALID.ADDRESS> a écrit :

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Heu.. oui et non. Un exemple, ma boite à mis en place depuis peu un
webmail accessible en https, or il se trouve que le certificat n'est pas
signé par une des autorités qui est installé chez le client où je
travaille actuellement. Résultat, à chaque fois que je me connecte, j'ai
le droit à un beau message et une belle couleur rouge à coté de la barre
d'adresse.

Moui, enfin l'admin à le choix, soit de se faire certifier par une
autorité présente dans le magasin par défaut, soit d'ajouter la sienne
dans ton navigateur...

Le WPA en lieu et place de WEP.

Tiens, justement, combien de temps a-t-il fallu attendre avant que WPA
soit implémenté dans OpenBSD ? Je peux te dire que se fut pour moi
réellement contraignant.

La réponse a longtemps été ipsec chez eux. Ils n'ont pas tort. ipsec
sur du wifi, c'est sécurisé.

Le DEP

Je connais pas mais le premier lien google me dis :

Data Execution Prevention. Un truc de codeurs sous windows.
Sous OpenBSD c'est W^X.

ou l'ALSR. La segmentation de la mémoire. Tout ça c'est
invisible pour l'utilisateur; au final, c'est de la sécurité.

Effectivement, tu as raison (ce n'est pas ce que j'ai en tête lorsque je
parle de sécurité pour l'utilisateur final). D'un autre coté, c'est un
peu comme si on parle d'un composant d'une serrure qui permet de
retarder son ouverture alors que la fenêtre d'à coté est grande ouverte.

Oui, enfin, je parlais de sécurité "qui marche". Ca, ça marche. On pourrait
encore citer pleins de trucs. Le fichier shadow. Le sel+hash pour
stocker les mots de passe. C'est bien. Pris seul, ça ne résoud rien,
mais l'ensemble permet d'avoir un système un peu mieux sécurisé.

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Contraintes? D'avoir une puce TPM? (le mode clé USB n'amène rien). Tu
achètes une machine avec TPM, tu la donnes à un youser de base, et
tu gagnes en sécurité: le disque est chiffré, garantie de confidentialité
en cas de perte ou vol et il n'y a pas de mot de passe, le youseur ne se
rend compte de rien et ne risque pas d'oublier son mot passe ou de le
mettre sur un postit puisqu'il n'en a pas.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

Justement, pour en revenir au sujet du thread, je vois pas comment on
peu avoir une authentification par mot de passe sécurisée sans avoir un
mot de passe un minimum complexe. C'est une contrainte et je n'ai pas vu
de solution à ce problème (ou j'ai mal lu).

Carte à puce. En plus, l'"éducation" (mais je n'aime pas ce mot) des
utilisateurs est rapide: il suffit de dire que c'est comme une carte
bleue et que cela demande un PIN. Couplé à un SSO, on résoud d'un
coup tous ces ennuis de mots de passes.
Je connais quelqu'un qui doit entrer un mot de passe différent par
appli web auquel il se connecte dans sa boite. Et là, on tombe sur
des politiques de sécurité de grand n'importe quoi avec des changements
de mdp ineptes comme on parlait plus haut.. (et lors de l'arrivée dans
la boite tous les mots de passe dérivent du nom et prénom du youseur
avec un tout petit variant; autant dire qu'il est possible de toujours
trouver une appli sur laquelle on peut se logger car l'user n'est pas
allé changer son mot de passe sur celle-ci...)

Pour la complexité des "mots de passe" le lien que j'ai fourni plus
haut sur une conférence du SSTIC montre qu'aujourd'hui sous windows,
le mot de passe Bonjour123 est aussi sécurisé que l33t_H4x0R!, donc
le "minimum complexe" reste très raisonnable. Ca doit être le cas
sous linux aussi.
--
Kevin

Vous avez filtré cet utilisateur ! Consultez son message

Le 05-03-2011, Benoit Izac a écrit :

Sans contrainte pour l'utilisateur final. Un exemple: le https.
L'utilisateur ne sait même pas que ça existe, au final, c'est
sécurisé [1].

Heu.. oui et non. Un exemple, ma boite à mis en place depuis peu un
webmail accessible en https, or il se trouve que le certificat n'est pas
signé par une des autorités qui est installé chez le client où je
travaille actuellement. Résultat, à chaque fois que je me connecte, j'ai
le droit à un beau message et une belle couleur rouge à coté de la barre
d'adresse.

Moui, enfin l'admin à le choix, soit de se faire certifier par une
autorité présente dans le magasin par défaut, soit d'ajouter la sienne
dans ton navigateur...

Le WPA en lieu et place de WEP.

Tiens, justement, combien de temps a-t-il fallu attendre avant que WPA
soit implémenté dans OpenBSD ? Je peux te dire que se fut pour moi
réellement contraignant.

La réponse a longtemps été ipsec chez eux. Ils n'ont pas tort. ipsec
sur du wifi, c'est sécurisé.

Le DEP

Je connais pas mais le premier lien google me dis :

Data Execution Prevention. Un truc de codeurs sous windows.
Sous OpenBSD c'est W^X.

ou l'ALSR. La segmentation de la mémoire. Tout ça c'est
invisible pour l'utilisateur; au final, c'est de la sécurité.

Effectivement, tu as raison (ce n'est pas ce que j'ai en tête lorsque je
parle de sécurité pour l'utilisateur final). D'un autre coté, c'est un
peu comme si on parle d'un composant d'une serrure qui permet de
retarder son ouverture alors que la fenêtre d'à coté est grande ouverte.

Oui, enfin, je parlais de sécurité "qui marche". Ca, ça marche. On pourrait
encore citer pleins de trucs. Le fichier shadow. Le sel+hash pour
stocker les mots de passe. C'est bien. Pris seul, ça ne résoud rien,
mais l'ensemble permet d'avoir un système un peu mieux sécurisé.

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Contraintes? D'avoir une puce TPM? (le mode clé USB n'amène rien). Tu
achètes une machine avec TPM, tu la donnes à un youser de base, et
tu gagnes en sécurité: le disque est chiffré, garantie de confidentialité
en cas de perte ou vol et il n'y a pas de mot de passe, le youseur ne se
rend compte de rien et ne risque pas d'oublier son mot passe ou de le
mettre sur un postit puisqu'il n'en a pas.

Obliger l'utilisateur a employer des mots de passe de +9 caractères
avec maj min chiffrs symboles qui changent tous les 12 jours, c'est
de la sécurité mais qui ne sera jamais acceptée, et qui sera donc
contournée. Donc, il vaut mieux mettre cette idée à la corbeille et
trouver autre chose.

Justement, pour en revenir au sujet du thread, je vois pas comment on
peu avoir une authentification par mot de passe sécurisée sans avoir un
mot de passe un minimum complexe. C'est une contrainte et je n'ai pas vu
de solution à ce problème (ou j'ai mal lu).

Carte à puce. En plus, l'"éducation" (mais je n'aime pas ce mot) des
utilisateurs est rapide: il suffit de dire que c'est comme une carte
bleue et que cela demande un PIN. Couplé à un SSO, on résoud d'un
coup tous ces ennuis de mots de passes.
Je connais quelqu'un qui doit entrer un mot de passe différent par
appli web auquel il se connecte dans sa boite. Et là, on tombe sur
des politiques de sécurité de grand n'importe quoi avec des changements
de mdp ineptes comme on parlait plus haut.. (et lors de l'arrivée dans
la boite tous les mots de passe dérivent du nom et prénom du youseur
avec un tout petit variant; autant dire qu'il est possible de toujours
trouver une appli sur laquelle on peut se logger car l'user n'est pas
allé changer son mot de passe sur celle-ci...)

Pour la complexité des "mots de passe" le lien que j'ai fourni plus
haut sur une conférence du SSTIC montre qu'aujourd'hui sous windows,
le mot de passe Bonjour123 est aussi sécurisé que l33t_H4x0R!, donc
le "minimum complexe" reste très raisonnable. Ca doit être le cas
sous linux aussi.
--
Kevin

Bruno Tréguier

06/03/2011 à 21:36

Le 06/03/2011 à 7:00, Fabien LE LEZ a écrit :

On Sat, 05 Mar 2011 14:29:08 +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.

Justement, de l'EEPROM, ça ne s'efface pas comme ça, d'un coup de
baguette magique. Si mes souvenirs sont bons, il faut lui balancer du
24 volts dans les dents. Du coup, remplacer le contenu d'une EEPROM
par logiciel, je ne suis pas sûr que ça se fasse.

C'est effectivement ce genre de tension qu'il faut en règle générale,
mais il me semble que certains types d'EEPROM (peu nombreuses)
comportent en interne leur propre circuiterie permettant un effacement
et une reprogrammation in situ. Cela ne change de toute façon pas
grand-chose à l'affaire: nous sommes d'accord sur le fait que le risque
d'altération du fonctionnement d'un lecteur de disquettes par un malware
(notamment pour bypasser la protection en écriture) est nulle.

Cordialement,

--
Bruno Tréguier

JKB

06/03/2011 à 22:37

Le Sun, 06 Mar 2011 21:36:33 +0100,
Bruno Tréguier écrivait :

Le 06/03/2011 à 7:00, Fabien LE LEZ a écrit :
On Sat, 05 Mar 2011 14:29:08 +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.

Justement, de l'EEPROM, ça ne s'efface pas comme ça, d'un coup de
baguette magique. Si mes souvenirs sont bons, il faut lui balancer du
24 volts dans les dents. Du coup, remplacer le contenu d'une EEPROM
par logiciel, je ne suis pas sûr que ça se fasse.

C'est effectivement ce genre de tension qu'il faut en règle générale,
mais il me semble que certains types d'EEPROM (peu nombreuses)
comportent en interne leur propre circuiterie permettant un effacement
et une reprogrammation in situ. Cela ne change de toute façon pas
grand-chose à l'affaire: nous sommes d'accord sur le fait que le risque
d'altération du fonctionnement d'un lecteur de disquettes par un malware
(notamment pour bypasser la protection en écriture) est nulle.

J'ai eu des EEPROM qui tournaient en 12V (écriture, pas lecture) et
d'autres en tension encore plus basse.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Benoit Izac

07/03/2011 à 16:48

Bonjour,

le 06/03/2011 à 20:03, Kevin Denis a écrit dans le message
:

Bitlocker, c'est très bien: le disque est chiffré sans mot de passe!
L'utilisateur lance le système, et il démarre sans rien demander
a l'utilisateur.

Je ne connais pas mais selon wikipedia, ça a quand même quelques
contraintes (TPM et/ou clé USB).

Contraintes? D'avoir une puce TPM? (le mode clé USB n'amène rien). Tu
achètes une machine avec TPM, tu la donnes à un youser de base, et
tu gagnes en sécurité: le disque est chiffré, garantie de confidentialité
en cas de perte ou vol et il n'y a pas de mot de passe, le youseur ne se
rend compte de rien et ne risque pas d'oublier son mot passe ou de le
mettre sur un postit puisqu'il n'en a pas.

Pour une grosse société soucieuse de sa sécurité, pourquoi pas. Pour une
PME ou un particulier, déjà le TPM c'est rare, ensuite windows 7, je
n'ai pas encore vu dans ma société et pour finir les compétences pour le
mettre en place ne court pas les rues.

Pour la complexité des "mots de passe" le lien que j'ai fourni plus
haut sur une conférence du SSTIC montre qu'aujourd'hui sous windows,
le mot de passe Bonjour123 est aussi sécurisé que l33t_H4x0R!, donc
le "minimum complexe" reste très raisonnable. Ca doit être le cas
sous linux aussi.

J'en doute fortement.

--
Benoit Izac

Nicolas Richard

07/03/2011 à 17:19

Le 28/02/11 01:26, Aeris a écrit :

Par exemple avec un mot de passe de 5 caratères uniquement en minuscules, il
n'y a «que» 11 881 376 possibilités. Avec 1ms par tentative, il faudrait
3.3 heures, ce qui semble réalisable.

cela ne peut être vrai que si:
- l'attaquant sait que (ou fait comme si) il n'y a que des minuscules
Sinon il va chercher parmi beaucoup plus de possibilités pour
finalement, s'il attend assez, trouver un mot de passe ne contenant que
des minuscules. Ceci est justement l'objet de la question du PO.

[La réaction "ah zut, si j'avais su qu'il n'y avait que des minuscules
je n'aurais cherché que ça !" est du même type que "ah zut, si j'avais
su que le mot de passe était abcfe je n'aurais essayé que ça !"]

- le mot de passe correct est le dernier essayé par l'attaquant.
Sinon il trouvera bien sûr avant d'avoir épuisé tous les cas. On peut
j'imagine tabler sur une espérance égale à la moitié du temps nécessaire
à vérifier tous les cas.

Avec une 10aine de caractères spéciaux en plus, on monte à 916 132 832
possibilités, soit 10.6 jours de calculs! En plus de ça le mot de passe n'a
aucune raison de se trouver dans une attaque par dictionnaire «classique»
qui se limite à des termes connus.

en cas d'attaque exclusivement par dictionnaire, le nombre de tentatives
réalisées est évidemment largement réduit, même dans les cas précédents.
Cela dit, je suppose que par "dictionnaire" il ne faut pas s'imaginer le
petit robert : c'est juste que l'attaquant commence par tester les mots
de passes les plus "probables" (qu'ils s'agisse de mots d'une langue
écrite ou pas).

Si on passe à 10 caractères avec majuscules et caractères spéciaux, on en
arrive à 839 299 365 868 340 200 possibilités et 26 614 008 années de

mon 'bc' me dit :
62^10 = 839 299 365 868 340 224
où sont les 24 possibilités manquantes ? ;)

Ça ne rendra donc pas ton mot de passe inviolable mais ça découragera et
rendra totalement inutile toute tentative de bruteforce dessus.

ça ne découragera pas un attaquant qui ne sait pas quels type de
caractères sont dans le mot de passe.
« Ils ne savaient que c’était impossible, alors ils l’ont fait. »

--
Nico.

Le 28/02/11 01:26, Aeris a écrit :

Par exemple avec un mot de passe de 5 caratères uniquement en minuscules, il
n'y a «que» 11 881 376 possibilités. Avec 1ms par tentative, il faudrait
3.3 heures, ce qui semble réalisable.

cela ne peut être vrai que si:
- l'attaquant sait que (ou fait comme si) il n'y a que des minuscules
Sinon il va chercher parmi beaucoup plus de possibilités pour
finalement, s'il attend assez, trouver un mot de passe ne contenant que
des minuscules. Ceci est justement l'objet de la question du PO.

[La réaction "ah zut, si j'avais su qu'il n'y avait que des minuscules
je n'aurais cherché que ça !" est du même type que "ah zut, si j'avais
su que le mot de passe était abcfe je n'aurais essayé que ça !"]

- le mot de passe correct est le dernier essayé par l'attaquant.
Sinon il trouvera bien sûr avant d'avoir épuisé tous les cas. On peut
j'imagine tabler sur une espérance égale à la moitié du temps nécessaire
à vérifier tous les cas.

Avec une 10aine de caractères spéciaux en plus, on monte à 916 132 832
possibilités, soit 10.6 jours de calculs! En plus de ça le mot de passe n'a
aucune raison de se trouver dans une attaque par dictionnaire «classique»
qui se limite à des termes connus.

en cas d'attaque exclusivement par dictionnaire, le nombre de tentatives
réalisées est évidemment largement réduit, même dans les cas précédents.
Cela dit, je suppose que par "dictionnaire" il ne faut pas s'imaginer le
petit robert : c'est juste que l'attaquant commence par tester les mots
de passes les plus "probables" (qu'ils s'agisse de mots d'une langue
écrite ou pas).

Si on passe à 10 caractères avec majuscules et caractères spéciaux, on en
arrive à 839 299 365 868 340 200 possibilités et 26 614 008 années de

mon 'bc' me dit :
62^10 = 839 299 365 868 340 224
où sont les 24 possibilités manquantes ? ;)

Ça ne rendra donc pas ton mot de passe inviolable mais ça découragera et
rendra totalement inutile toute tentative de bruteforce dessus.

ça ne découragera pas un attaquant qui ne sait pas quels type de
caractères sont dans le mot de passe.
« Ils ne savaient que c’était impossible, alors ils l’ont fait. »

--
Nico.

Vous avez filtré cet utilisateur ! Consultez son message

Le 28/02/11 01:26, Aeris a écrit :

Par exemple avec un mot de passe de 5 caratères uniquement en minuscules, il
n'y a «que» 11 881 376 possibilités. Avec 1ms par tentative, il faudrait
3.3 heures, ce qui semble réalisable.

cela ne peut être vrai que si:
- l'attaquant sait que (ou fait comme si) il n'y a que des minuscules
Sinon il va chercher parmi beaucoup plus de possibilités pour
finalement, s'il attend assez, trouver un mot de passe ne contenant que
des minuscules. Ceci est justement l'objet de la question du PO.

[La réaction "ah zut, si j'avais su qu'il n'y avait que des minuscules
je n'aurais cherché que ça !" est du même type que "ah zut, si j'avais
su que le mot de passe était abcfe je n'aurais essayé que ça !"]

- le mot de passe correct est le dernier essayé par l'attaquant.
Sinon il trouvera bien sûr avant d'avoir épuisé tous les cas. On peut
j'imagine tabler sur une espérance égale à la moitié du temps nécessaire
à vérifier tous les cas.

Avec une 10aine de caractères spéciaux en plus, on monte à 916 132 832
possibilités, soit 10.6 jours de calculs! En plus de ça le mot de passe n'a
aucune raison de se trouver dans une attaque par dictionnaire «classique»
qui se limite à des termes connus.

en cas d'attaque exclusivement par dictionnaire, le nombre de tentatives
réalisées est évidemment largement réduit, même dans les cas précédents.
Cela dit, je suppose que par "dictionnaire" il ne faut pas s'imaginer le
petit robert : c'est juste que l'attaquant commence par tester les mots
de passes les plus "probables" (qu'ils s'agisse de mots d'une langue
écrite ou pas).

Si on passe à 10 caractères avec majuscules et caractères spéciaux, on en
arrive à 839 299 365 868 340 200 possibilités et 26 614 008 années de

mon 'bc' me dit :
62^10 = 839 299 365 868 340 224
où sont les 24 possibilités manquantes ? ;)

Ça ne rendra donc pas ton mot de passe inviolable mais ça découragera et
rendra totalement inutile toute tentative de bruteforce dessus.

ça ne découragera pas un attaquant qui ne sait pas quels type de
caractères sont dans le mot de passe.
« Ils ne savaient que c’était impossible, alors ils l’ont fait. »

--
Nico.

sécurité des mots de passe

10 réponses

Veuillez sélectionner un problème