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... ?
Le Fri, 04 Mar 2011 04:11:49 +0100, Fabien LE LEZ a écrit :
Pour moi, ça fait partie des habitudes dont plus personne ne connaît la source. En anglais, ça s'appelle "cargo cult", mais je ne sais pas s'il y a un équivalent en français.
Autres trucs du même style :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
Tout simplement pour neutraliser les attaques par force brute sur le compte root. Si un compte non privilégié est compromis, c'est ennuyeux, mais encore détectable, et ça laisse du temps pour (ré)agir. C'est c'est le compte root... game over !
accessoirement, ça permet aussi de logguer quel admin a fait quoi via les traces que sudo (plutot que su) aura laissé dans les logs
-- Rico Partout où la religion règne, ne voyons-nous pas des peuples asservis ? -+- Paul D'Holbach -+-
Le Fri, 04 Mar 2011 04:11:49 +0100, Fabien LE LEZ a écrit :
Pour moi, ça fait partie des habitudes dont plus personne ne connaît la
source. En anglais, ça s'appelle "cargo cult", mais je ne sais pas s'il
y a un équivalent en français.
Autres trucs du même style :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se
connecter en tant qu'utilisateur puis utiliser "su".
Tout simplement pour neutraliser les attaques par force brute sur le
compte root.
Si un compte non privilégié est compromis, c'est ennuyeux, mais encore
détectable, et ça laisse du temps pour (ré)agir. C'est c'est le compte
root... game over !
accessoirement, ça permet aussi de logguer quel admin a fait quoi via les
traces que sudo (plutot que su) aura laissé dans les logs
--
Rico
Partout où la religion règne, ne voyons-nous pas des peuples asservis ?
-+- Paul D'Holbach -+-
Le Fri, 04 Mar 2011 04:11:49 +0100, Fabien LE LEZ a écrit :
Pour moi, ça fait partie des habitudes dont plus personne ne connaît la source. En anglais, ça s'appelle "cargo cult", mais je ne sais pas s'il y a un équivalent en français.
Autres trucs du même style :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
Tout simplement pour neutraliser les attaques par force brute sur le compte root. Si un compte non privilégié est compromis, c'est ennuyeux, mais encore détectable, et ça laisse du temps pour (ré)agir. C'est c'est le compte root... game over !
accessoirement, ça permet aussi de logguer quel admin a fait quoi via les traces que sudo (plutot que su) aura laissé dans les logs
-- Rico Partout où la religion règne, ne voyons-nous pas des peuples asservis ? -+- Paul D'Holbach -+-
Eric Belhomme
Le Fri, 04 Mar 2011 12:40:39 +0100, J.P. Kuypers a écrit :
Il y a des SAV qui considèrent que de telles pratiques annulent la garantie. N'est-ce pas en contradiction avec l'une ou l'autre directives européennes ?...
Dans le grand public, certainement, mais pas chez les pros ! En 10 ans j'ai arrêté de compter le nombre de disques que je retournais à Dell, HP, IBM, EMC ou NetApp en ayant préalablement pris soin de défoncer le disque à coups de marteau, et aucune de ces boites ne m'a jamais ennuyé à ce sujet !
-- Rico Les forêts précèdent les peuples, les déserts les suivent. -+- François René de Chateaubriand -+-
Le Fri, 04 Mar 2011 12:40:39 +0100, J.P. Kuypers a écrit :
Il y a des SAV qui considèrent que de telles pratiques annulent la
garantie. N'est-ce pas en contradiction avec l'une ou l'autre directives
européennes ?...
Dans le grand public, certainement, mais pas chez les pros !
En 10 ans j'ai arrêté de compter le nombre de disques que je retournais à
Dell, HP, IBM, EMC ou NetApp en ayant préalablement pris soin de défoncer
le disque à coups de marteau, et aucune de ces boites ne m'a jamais
ennuyé à ce sujet !
--
Rico
Les forêts précèdent les peuples, les déserts les suivent.
-+- François René de Chateaubriand -+-
Le Fri, 04 Mar 2011 12:40:39 +0100, J.P. Kuypers a écrit :
Il y a des SAV qui considèrent que de telles pratiques annulent la garantie. N'est-ce pas en contradiction avec l'une ou l'autre directives européennes ?...
Dans le grand public, certainement, mais pas chez les pros ! En 10 ans j'ai arrêté de compter le nombre de disques que je retournais à Dell, HP, IBM, EMC ou NetApp en ayant préalablement pris soin de défoncer le disque à coups de marteau, et aucune de ces boites ne m'a jamais ennuyé à ce sujet !
-- Rico Les forêts précèdent les peuples, les déserts les suivent. -+- François René de Chateaubriand -+-
Eric Belhomme
Le Fri, 04 Mar 2011 13:52:58 +0100, Bruno Tréguier a écrit :
En utilisant une paire de clefs et en bloquant toute possibilité d'utiliser des mots de passe, c'est déjà plus sûr, et on n'a pas besoin, je pense, de passer par la double étape "ssh" puis "su"...
Il est parfois utile de pouvoir se connecter sur un serveur distant, même si on a pas sur soi sa clé privée. Exemple, au hasard, je suis en vacances, et on m'appelle pour dépanner le serveur mail de l'entreprise qui est en carafe, je peux utiliser l'ordinateur de ma maman pour me connecter au biniou et fixer le problème. C'est plus difficile si j'ai un auth par clé privée exclusive sur cette machine *
Possible aussi en mettant le niveau de log de sshd à "VERBOSE" dans sshd_config, cela permet de loguer la clef publique qui a été utilisée pour accéder au compte.
Dans le cadre d'une administration à plusieurs admins, ça ne permet pas de tracer qui fait quoi, ce qui est essentiel. sudo le permet. En fait, je suis d'avis, et je force mes collègues à utiliser leurs comptes réguliers et à ne faire des élévations de privilèges via sudo, lorsque c'est nécessaire **
* ok, je pourrais avoir ma clé toujours sur moi, sur un tocken USB ou autre, sauf que je ne dispose pas de ce genre de techno...
** j'avoue, je "sudo su root -" dès que j'ai de *grosses* opérations de maintenance à effectuer..
-- Rico Hélas que sert la bonne chère Quand on n'a pas la liberté ! -+- Jean de La Fontaine (1621-1695), Le Cheval s'étant voulu venger du Cerf (Fables IV.13) -+-
Le Fri, 04 Mar 2011 13:52:58 +0100, Bruno Tréguier a écrit :
En utilisant une paire de clefs et en bloquant toute possibilité
d'utiliser des mots de passe, c'est déjà plus sûr, et on n'a pas besoin,
je pense, de passer par la double étape "ssh" puis "su"...
Il est parfois utile de pouvoir se connecter sur un serveur distant, même
si on a pas sur soi sa clé privée. Exemple, au hasard, je suis en
vacances, et on m'appelle pour dépanner le serveur mail de l'entreprise
qui est en carafe, je peux utiliser l'ordinateur de ma maman pour me
connecter au biniou et fixer le problème. C'est plus difficile si j'ai un
auth par clé privée exclusive sur cette machine *
Possible aussi en mettant le niveau de log de sshd à "VERBOSE" dans
sshd_config, cela permet de loguer la clef publique qui a été utilisée
pour accéder au compte.
Dans le cadre d'une administration à plusieurs admins, ça ne permet pas
de tracer qui fait quoi, ce qui est essentiel. sudo le permet. En fait,
je suis d'avis, et je force mes collègues à utiliser leurs comptes
réguliers et à ne faire des élévations de privilèges via sudo, lorsque
c'est nécessaire **
* ok, je pourrais avoir ma clé toujours sur moi, sur un tocken USB ou
autre, sauf que je ne dispose pas de ce genre de techno...
** j'avoue, je "sudo su root -" dès que j'ai de *grosses* opérations de
maintenance à effectuer..
--
Rico
Hélas que sert la bonne chère
Quand on n'a pas la liberté !
-+- Jean de La Fontaine (1621-1695),
Le Cheval s'étant voulu venger du Cerf (Fables IV.13) -+-
Le Fri, 04 Mar 2011 13:52:58 +0100, Bruno Tréguier a écrit :
En utilisant une paire de clefs et en bloquant toute possibilité d'utiliser des mots de passe, c'est déjà plus sûr, et on n'a pas besoin, je pense, de passer par la double étape "ssh" puis "su"...
Il est parfois utile de pouvoir se connecter sur un serveur distant, même si on a pas sur soi sa clé privée. Exemple, au hasard, je suis en vacances, et on m'appelle pour dépanner le serveur mail de l'entreprise qui est en carafe, je peux utiliser l'ordinateur de ma maman pour me connecter au biniou et fixer le problème. C'est plus difficile si j'ai un auth par clé privée exclusive sur cette machine *
Possible aussi en mettant le niveau de log de sshd à "VERBOSE" dans sshd_config, cela permet de loguer la clef publique qui a été utilisée pour accéder au compte.
Dans le cadre d'une administration à plusieurs admins, ça ne permet pas de tracer qui fait quoi, ce qui est essentiel. sudo le permet. En fait, je suis d'avis, et je force mes collègues à utiliser leurs comptes réguliers et à ne faire des élévations de privilèges via sudo, lorsque c'est nécessaire **
* ok, je pourrais avoir ma clé toujours sur moi, sur un tocken USB ou autre, sauf que je ne dispose pas de ce genre de techno...
** j'avoue, je "sudo su root -" dès que j'ai de *grosses* opérations de maintenance à effectuer..
-- Rico Hélas que sert la bonne chère Quand on n'a pas la liberté ! -+- Jean de La Fontaine (1621-1695), Le Cheval s'étant voulu venger du Cerf (Fables IV.13) -+-
Nicolas George
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.
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.
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.
Nicolas George
Eric Belhomme , dans le message <4d70f2ed$0$7176$, a écrit :
Exemple, au hasard, je suis en vacances, et on m'appelle pour dépanner le serveur mail de l'entreprise qui est en carafe, je peux utiliser l'ordinateur de ma maman pour me connecter au biniou
Et bonjour le keylogger dans l'ordi vérolé.
et fixer le problème.
Tu le fixes droit dans les yeux ou tu le fixes au mur avec une punaise ?
* ok, je pourrais avoir ma clé toujours sur moi, sur un tocken USB ou autre, sauf que je ne dispose pas de ce genre de techno...
Une clef USB, ça coûte presque rien ete c'est bien pratique de temps en temps.
Eric Belhomme , dans le message <4d70f2ed$0$7176$426a34cc@news.free.fr>,
a écrit :
Exemple, au hasard, je suis en
vacances, et on m'appelle pour dépanner le serveur mail de l'entreprise
qui est en carafe, je peux utiliser l'ordinateur de ma maman pour me
connecter au biniou
Et bonjour le keylogger dans l'ordi vérolé.
et fixer le problème.
Tu le fixes droit dans les yeux ou tu le fixes au mur avec une punaise ?
* ok, je pourrais avoir ma clé toujours sur moi, sur un tocken USB ou
autre, sauf que je ne dispose pas de ce genre de techno...
Une clef USB, ça coûte presque rien ete c'est bien pratique de temps en
temps.
Eric Belhomme , dans le message <4d70f2ed$0$7176$, a écrit :
Exemple, au hasard, je suis en vacances, et on m'appelle pour dépanner le serveur mail de l'entreprise qui est en carafe, je peux utiliser l'ordinateur de ma maman pour me connecter au biniou
Et bonjour le keylogger dans l'ordi vérolé.
et fixer le problème.
Tu le fixes droit dans les yeux ou tu le fixes au mur avec une punaise ?
* ok, je pourrais avoir ma clé toujours sur moi, sur un tocken USB ou autre, sauf que je ne dispose pas de ce genre de techno...
Une clef USB, ça coûte presque rien ete c'est bien pratique de temps en temps.
Benoit Izac
Bonjour,
le 04/03/2011 à 12:28, Kevin Denis a écrit dans le message :
De toute manière à partir du moment où on a un accès physique à la machine et que le disque n'est pas chiffré,
et s'il est chiffré, c'est pareil. Il suffit de modifier le bootloader pour faire un peu ce que l'on souhaite: ajouter une clé LUKS dans un slot sous linux,
Chez moi, il me demande un mot de passe pour en ajouter un dans un autre slot donc je vois pas trop comment tu procèdes.
logger le mot de passe n'importe où, ajouter une clé RSA dans le .ssh/authorized_keys de root.
Ben justement comment tu fais pour ajouter un clé dans un espace où tu ne peux pas accéder ?
Puis attendre que la victime se reconnecte à sa machine.
Le chiffrement de disque ne protège que lorsque l'attaquant à accès à ta machine ET que tu le sais. Sinon, le chiffrement est useless..
C'est vrai qu'on peu modifier l'initrd et ainsi récupérer le mot de passe. En revanche, si je mets mon /boot sur une clé USB, je vois pas trop comment un attaquant peu agir.
-- Benoit Izac
Bonjour,
le 04/03/2011 à 12:28, Kevin Denis a écrit dans le message
<slrnin1n5k.fkj.kevin@slackwall.local.tux> :
De toute manière à partir du moment où on a un accès physique à la
machine et que le disque n'est pas chiffré,
et s'il est chiffré, c'est pareil. Il suffit de modifier le bootloader
pour faire un peu ce que l'on souhaite: ajouter une clé LUKS dans un
slot sous linux,
Chez moi, il me demande un mot de passe pour en ajouter un dans un autre
slot donc je vois pas trop comment tu procèdes.
logger le mot de passe n'importe où, ajouter une
clé RSA dans le .ssh/authorized_keys de root.
Ben justement comment tu fais pour ajouter un clé dans un espace où tu
ne peux pas accéder ?
Puis attendre que la victime se reconnecte à sa machine.
Le chiffrement de disque ne protège que lorsque l'attaquant à accès
à ta machine ET que tu le sais. Sinon, le chiffrement est useless..
C'est vrai qu'on peu modifier l'initrd et ainsi récupérer le mot de
passe. En revanche, si je mets mon /boot sur une clé USB, je vois pas
trop comment un attaquant peu agir.
le 04/03/2011 à 12:28, Kevin Denis a écrit dans le message :
De toute manière à partir du moment où on a un accès physique à la machine et que le disque n'est pas chiffré,
et s'il est chiffré, c'est pareil. Il suffit de modifier le bootloader pour faire un peu ce que l'on souhaite: ajouter une clé LUKS dans un slot sous linux,
Chez moi, il me demande un mot de passe pour en ajouter un dans un autre slot donc je vois pas trop comment tu procèdes.
logger le mot de passe n'importe où, ajouter une clé RSA dans le .ssh/authorized_keys de root.
Ben justement comment tu fais pour ajouter un clé dans un espace où tu ne peux pas accéder ?
Puis attendre que la victime se reconnecte à sa machine.
Le chiffrement de disque ne protège que lorsque l'attaquant à accès à ta machine ET que tu le sais. Sinon, le chiffrement est useless..
C'est vrai qu'on peu modifier l'initrd et ainsi récupérer le mot de passe. En revanche, si je mets mon /boot sur une clé USB, je vois pas trop comment un attaquant peu agir.
-- Benoit Izac
Nicolas George
Benoit Izac , dans le message , a écrit :
En revanche, si je mets mon /boot sur une clé USB, je vois pas trop comment un attaquant peu agir.
Si tu mets ton /boot sur clef USB, on ne peut plus dire que l'attaquant a accès physique à la machine. Il n'a accès physique qu'à 99% de la machine.
Benoit Izac , dans le message <874o7ivp6h.fsf@izac.org>, a écrit :
En revanche, si je mets mon /boot sur une clé USB, je vois pas
trop comment un attaquant peu agir.
Si tu mets ton /boot sur clef USB, on ne peut plus dire que l'attaquant a
accès physique à la machine. Il n'a accès physique qu'à 99% de la machine.
En revanche, si je mets mon /boot sur une clé USB, je vois pas trop comment un attaquant peu agir.
Si tu mets ton /boot sur clef USB, on ne peut plus dire que l'attaquant a accès physique à la machine. Il n'a accès physique qu'à 99% de la machine.
Kevin Denis
Le 04-03-2011, Benoit Izac a écrit :
De toute manière à partir du moment où on a un accès physique à la machine et que le disque n'est pas chiffré,
et s'il est chiffré, c'est pareil. Il suffit de modifier le bootloader pour faire un peu ce que l'on souhaite: ajouter une clé LUKS dans un slot sous linux,
Chez moi, il me demande un mot de passe pour en ajouter un dans un autre slot donc je vois pas trop comment tu procèdes.
en modifiant l'initrd (ou tout autre bootloader/mécanisme de démarrage) d'un système utilisant une racine chiffrée.
logger le mot de passe n'importe où, ajouter une clé RSA dans le .ssh/authorized_keys de root.
Ben justement comment tu fais pour ajouter un clé dans un espace où tu ne peux pas accéder ?
Depuis l'initrd, si, puisque le mot de passe est fourni gracieusement par la victime.
Puis attendre que la victime se reconnecte à sa machine.
Le chiffrement de disque ne protège que lorsque l'attaquant à accès à ta machine ET que tu le sais. Sinon, le chiffrement est useless..
C'est vrai qu'on peu modifier l'initrd et ainsi récupérer le mot de passe. En revanche, si je mets mon /boot sur une clé USB, je vois pas trop comment un attaquant peu agir.
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est contraignant. -- Kevin
Le 04-03-2011, Benoit Izac <use.reply.to@INVALID.ADDRESS> a écrit :
De toute manière à partir du moment où on a un accès physique à la
machine et que le disque n'est pas chiffré,
et s'il est chiffré, c'est pareil. Il suffit de modifier le bootloader
pour faire un peu ce que l'on souhaite: ajouter une clé LUKS dans un
slot sous linux,
Chez moi, il me demande un mot de passe pour en ajouter un dans un autre
slot donc je vois pas trop comment tu procèdes.
en modifiant l'initrd (ou tout autre bootloader/mécanisme de démarrage)
d'un système utilisant une racine chiffrée.
logger le mot de passe n'importe où, ajouter une
clé RSA dans le .ssh/authorized_keys de root.
Ben justement comment tu fais pour ajouter un clé dans un espace où tu
ne peux pas accéder ?
Depuis l'initrd, si, puisque le mot de passe est fourni gracieusement
par la victime.
Puis attendre que la victime se reconnecte à sa machine.
Le chiffrement de disque ne protège que lorsque l'attaquant à accès
à ta machine ET que tu le sais. Sinon, le chiffrement est useless..
C'est vrai qu'on peu modifier l'initrd et ainsi récupérer le mot de
passe. En revanche, si je mets mon /boot sur une clé USB, je vois pas
trop comment un attaquant peu agir.
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est
contraignant.
--
Kevin
De toute manière à partir du moment où on a un accès physique à la machine et que le disque n'est pas chiffré,
et s'il est chiffré, c'est pareil. Il suffit de modifier le bootloader pour faire un peu ce que l'on souhaite: ajouter une clé LUKS dans un slot sous linux,
Chez moi, il me demande un mot de passe pour en ajouter un dans un autre slot donc je vois pas trop comment tu procèdes.
en modifiant l'initrd (ou tout autre bootloader/mécanisme de démarrage) d'un système utilisant une racine chiffrée.
logger le mot de passe n'importe où, ajouter une clé RSA dans le .ssh/authorized_keys de root.
Ben justement comment tu fais pour ajouter un clé dans un espace où tu ne peux pas accéder ?
Depuis l'initrd, si, puisque le mot de passe est fourni gracieusement par la victime.
Puis attendre que la victime se reconnecte à sa machine.
Le chiffrement de disque ne protège que lorsque l'attaquant à accès à ta machine ET que tu le sais. Sinon, le chiffrement est useless..
C'est vrai qu'on peu modifier l'initrd et ainsi récupérer le mot de passe. En revanche, si je mets mon /boot sur une clé USB, je vois pas trop comment un attaquant peu agir.
Il faut que la clé USB ne soit jamais stockée avec le PC. C'est contraignant. -- Kevin
Eric Belhomme
Le Fri, 04 Mar 2011 17:33:02 +0100, Bruno Tréguier a écrit :
D'accord, mais comme dans beaucoup de cas, il s'agit ici encore d'une affaire de compromis entre l'étendue des fonctionnalités, et le risque accepté. C'est sûr que d'avoir une possibilité de se loguer en ssh sans clef privée, ça peut être sympa, mais si j'avais à faire ça, j'utiliserais quand-même une protection complémentaire: par exemple 2 daemons sshd, l'un n'acceptant que les connexions par clefs, l'autre acceptant aussi les mots de passe, mais protégé par un mécanisme de port-knocking pour éviter les tentatives de brute-forcing. De toute façon, quel que soit le mécanisme d'authentification utilisé, se connecter depuis une machine non maîtrisée est un risque (comme le dit d'ailleurs Nicolas George), après, c'est à chacun de se positionner par rapport à la politique de sécurité de l'entreprise et/ou la confiance que l'on peut avoir en la machine depuis laquelle on se connecte.
je ne peux que plussoyer : tout est question de compromis
Peut-être que la machine de la maman d'un admin a moins de chances d'être vérolée qu'une autre après tout... ;-)
bof, la maman de l'admin n'est pas l'admin...
-- Rico Quand vous doublez un cycliste, laissez-lui toujours la place de tomber. -+- Le Républicain Lorrain, 14/08/1954 -+-
Le Fri, 04 Mar 2011 17:33:02 +0100, Bruno Tréguier a écrit :
D'accord, mais comme dans beaucoup de cas, il s'agit ici encore d'une
affaire de compromis entre l'étendue des fonctionnalités, et le risque
accepté. C'est sûr que d'avoir une possibilité de se loguer en ssh sans
clef privée, ça peut être sympa, mais si j'avais à faire ça,
j'utiliserais quand-même une protection complémentaire: par exemple 2
daemons sshd, l'un n'acceptant que les connexions par clefs, l'autre
acceptant aussi les mots de passe, mais protégé par un mécanisme de
port-knocking pour éviter les tentatives de brute-forcing. De toute
façon, quel que soit le mécanisme d'authentification utilisé, se
connecter depuis une machine non maîtrisée est un risque (comme le dit
d'ailleurs Nicolas George), après, c'est à chacun de se positionner par
rapport à la politique de sécurité de l'entreprise et/ou la confiance
que l'on peut avoir en la machine depuis laquelle on se connecte.
je ne peux que plussoyer : tout est question de compromis
Peut-être que la machine de la maman d'un admin a moins de chances
d'être vérolée qu'une autre après tout... ;-)
bof, la maman de l'admin n'est pas l'admin...
--
Rico
Quand vous doublez un cycliste, laissez-lui toujours la place de tomber.
-+- Le Républicain Lorrain, 14/08/1954 -+-
Le Fri, 04 Mar 2011 17:33:02 +0100, Bruno Tréguier a écrit :
D'accord, mais comme dans beaucoup de cas, il s'agit ici encore d'une affaire de compromis entre l'étendue des fonctionnalités, et le risque accepté. C'est sûr que d'avoir une possibilité de se loguer en ssh sans clef privée, ça peut être sympa, mais si j'avais à faire ça, j'utiliserais quand-même une protection complémentaire: par exemple 2 daemons sshd, l'un n'acceptant que les connexions par clefs, l'autre acceptant aussi les mots de passe, mais protégé par un mécanisme de port-knocking pour éviter les tentatives de brute-forcing. De toute façon, quel que soit le mécanisme d'authentification utilisé, se connecter depuis une machine non maîtrisée est un risque (comme le dit d'ailleurs Nicolas George), après, c'est à chacun de se positionner par rapport à la politique de sécurité de l'entreprise et/ou la confiance que l'on peut avoir en la machine depuis laquelle on se connecte.
je ne peux que plussoyer : tout est question de compromis
Peut-être que la machine de la maman d'un admin a moins de chances d'être vérolée qu'une autre après tout... ;-)
bof, la maman de l'admin n'est pas l'admin...
-- Rico Quand vous doublez un cycliste, laissez-lui toujours la place de tomber. -+- Le Républicain Lorrain, 14/08/1954 -+-
Benoit Izac
Bonjour,
le 04/03/2011 à 17:29, 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. 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.
-- Benoit Izac
Bonjour,
le 04/03/2011 à 17:29, Kevin Denis a écrit dans le message
<slrnin28po.flf.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.
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.
le 04/03/2011 à 17:29, 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. 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.
