Est-il préférable d'utiliser une clé publique pour se connecter à SSH plutôt que d'enregistrer un mot de passe?

john

2011-05-17 21:26:31 UTC

view on stackexchange narkive permalink

Ma réponse est que l'utilisation de paires de clés publiques est une chose beaucoup plus sage à faire que l'utilisation de mots de passe ou de listes de mots de passe. Je vais me concentrer sur des éléments peu connus concernant les différentes formes d'authentification SSH, et je ne vois aucune autre réponse les mentionnant.

Tout d'abord, vous devez comprendre que l'authentification des utilisateurs est un processus différent et distinct de l'établissement du canal sécurisé . En termes simples, cela signifie d'abord que la clé publique du serveur est utilisée (si elle est acceptée!) Pour construire le canal SSH sécurisé, en permettant la négociation d'une clé symétrique qui sera utilisée pour protéger la session restante, activer le canal confidentialité, protection de l’intégrité et authentification du serveur.

Une fois le canal est fonctionnel et sécurisé, l’authentification de l’utilisateur a lieu. Les deux méthodes habituelles de le faire sont d’utiliser un mot de passe ou une paire de clés publiques.L'authentification par mot de passe fonctionne comme vous pouvez l'imaginer: le client envoie son mot de passe sur le canal sécurisé, le serveur vérifie qu'il s'agit bien du mot de passe de l'utilisateur spécifique et autorise l'accès.Dans le cas de la clé publique, nous avons une situation très différente. Dans ce cas, le serveur a la clé publique de l'utilisateur stockée. Ce qui se passe ensuite, c'est que le serveur crée une valeur aléatoire (nonce), la crypte avec la clé publique et l'envoie à l'utilisateur. Si l'utilisateur est censé être, il peut décrypter le défi et le renvoyer au serveur, qui confirme alors l'identité de l'utilisateur. Il s'agit du modèle défi-réponse classique. (En SSHv2, quelque chose d'un peu différent mais conceptuellement proche est en fait utilisé)

Comme vous pouvez l'imaginer, dans le premier cas, le mot de passe est en fait envoyé au serveur (à moins que SSH n'utilise une réponse de défi de mot de passe), dans le second, votre clé privée ne quitte jamais le client. Dans le scénario imaginaire où quelqu'un intercepte le trafic SSL et est capable de le déchiffrer (en utilisant une clé privée de serveur compromise, ou si vous acceptez une mauvaise clé publique lors de la connexion au serveur) ou a accès au serveur ou au client, votre mot de passe sera connu - avec l'authentification par clé publique-privée et le modèle de défi-réponse, vos détails privés ne tomberont jamais entre les mains de l'attaquant.Ainsi, même si un serveur auquel vous vous connectez est compromis, les autres serveurs pour lesquels vous utilisez la même clé ne !

Il y a d'autres avantages à utiliser une paire de clés publiques: La clé privée ne doit pas être stockée en clair sur votre ordinateur client comme vous le suggérez. Cela laisse bien sûr le fichier de clé privée ouvert à la compromission comme le ferait un fichier de mot de passe non chiffré, mais il est plus facile de déchiffrer (lors de la connexion) et d'utiliser la clé privée. Il doit être stocké chiffré et vous devez fournir une phrase de passe généralement longue pour le déchiffrer chaque fois qu'il est utilisé.

Bien sûr, cela signifie que vous devrez fournir le long mot de passe chaque fois que vous vous connectez à un serveur, pour déverrouiller votre clé privée - Il existe des moyens de contourner cela. Vous pouvez augmenter la convivialité du système en utilisant un agent d'authentification: il s'agit d'un logiciel qui déverrouille vos clés pour la session en cours, lorsque vous vous connectez à gnome par exemple ou lorsque vous ssh pour la première fois dans votre client, vous pouvez donc simplement tapez 'ssh remote-system-ip' et connectez-vous, sans fournir de phrase de passe, et faites-le plusieurs fois jusqu'à ce que vous vous déconnectiez de votre session.

Donc, pour résumer, l'utilisation de paires de clés publiques offre beaucoup plus de protection que l'utilisation de mots de passe ou de listes de mots de passe qui peuvent être capturés si le client , le serveur ou la session sécurisée est compromise . Dans le cas où vous n'utilisez pas de phrase de passe (ce qui ne devrait pas arriver), les paires de clés publiques offrent toujours une protection contre les sessions et les serveurs compromis.

Hmmm, je viens de relire la question et j'ai vu que cela demande spécifiquement de ne pas avoir de mot de passe pour la clé privée - je n'ai pas remarqué cela lors de l'écriture de la réponse. Bien sûr, il est toujours possible d'utiliser un agent, donc ne pas utiliser de phrase de passe n'est pas très intelligent.

Modification de la réponse pour refléter la bonne question (sans utiliser de phrases de passe).

Mes clés privées peuvent être décryptées automatiquement sur Ubuntu, leurs mots de passe sont cryptés avec mon mot de passe de connexion et Ubuntu les déverrouille automatiquement lorsque je me connecte. C'est vraiment le meilleur des deux mondes, car j'ai l'avantage d'un mot de passe sans mot de passe clé avec la sécurité d'un mot de passe (presque) .Si vous vous connectez à un système informatique de haute sécurité, cela peut ne pas être suffisamment sécurisé, car votre mot de passe de connexion peut être compromis assez facilement, et ainsi les phases de passe de vos clés peuvent être compromis aussi. Cependant, c'est bien mieux qu'une clé sans passphase.

Si «ne pas utiliser de phrase secrète n'est pas intelligent», alors pourquoi la [documentation OpenSSL] (http://www.openssl.org/docs/HOWTO/keys.txt) dit spécifiquement que «cela peut être une bonne chose éviter de le protéger avec un mot de passe "? (Dois-je poser cela comme une question indépendante?)

Certaines parties de cette réponse sont un peu trop détaillées et s'égarent en conséquence. La caractéristique distinctive de l'authentification publique dans ce contexte est que le client signe quelque chose avec sa clé privée et n'a pas besoin de révéler un secret dans le processus. L'authentification publique SSH-2 n'utilise pas réellement un protocole de défi-réponse comme décrit dans cette réponse. Le client signe une valeur qui est dérivée indépendamment par chaque côté dans le cadre du processus d'accord de clé symétrique; voir RFC-4252, section 7 (en particulier «l'identifiant de session»). Les deux parties y contribuent et aucune ne peut la déterminer.

L'utilisation de l'identifiant de session dans l'authentification publique a un effet intéressant qui n'est pas souvent remarqué: il offre une protection supplémentaire contre une attaque de type "man-in-the-middle". Si l'attaquant exécute l'échange de clés séparément de chaque côté, les identifiants de session (ID) seront différents. Le serveur demande une signature sur l'ID pour sa connexion avec l'attaquant - mais le client ne produira une signature que sur l'ID de son côté. L'attaquant n'a aucun moyen de les forcer à être identiques, et aucun moyen d'inciter le client à faire autre chose. Un protocole de défi-réponse ne ferait pas cela.

@RichardE.Silverman Vous devriez peut-être suggérer une modification. Il est peu probable que l'affiche édite lui-même étant donné qu'il n'est pas sur ce site depuis trois ans.

Thomas Pornin

2011-05-17 19:27:18 UTC

view on stackexchange narkive permalink

Par rapport à une liste stockée de mots de passe (longs et aléatoires), une clé privée SSH stockée offre la même sécurité : les choses sont en sécurité tant que votre fichier privé reste privé.

La clé privée, cependant, est beaucoup plus pratique , à la fois pratiquement (pour le moment, les clients SSH la prennent en charge prête à l'emploi, contrairement à un fichier personnalisé de mots de passe que vous devez utiliser avec une copie manuelle&paste) et théoriquement (vous pouvez réutiliser la même clé pour chaque hôte auquel vous souhaitez vous connecter, alors qu'une liste de mots de passe augmentera linéairement avec le nombre d'hôtes contactés, sauf si vous réutilisez le même mot de passe pour plusieurs hôtes, ce qui est mauvais ).

Je crains que certains lecteurs passent à côté des implications des «mots de passe longs et aléatoires». Une clé privée porte beaucoup plus d'entropie qu'un mot de passe réaliste (disons au moins 128 bits d'entropie, en supposant un RNG décent; un mot de passe de 10 caractères ASCII en a environ la moitié, beaucoup moins s'il est mémorable). De plus, les gens réutilisent les mots de passe beaucoup plus souvent que les clés privées. Ainsi, en pratique, une clé privée présente des avantages de sécurité.

Les clés asymétriques @Gilles comme celles utilisées dans SSH ont toutes au moins 1024 bits d'entropie, pas 128. Cependant, le cryptage asymétrique * nécessite * plus d'entropie. Une asymétrie de 1024 bits est plus faible que le cryptage symétrique de 128 bits. Lorsque quelqu'un essaie de forcer brutalement un serveur SSH, il doit le faire «lentement» pour éviter de créer une attaque par déni de service. Cela signifie qu'un mot de passe avec environ 50 bits d'entropie prendra des centaines de millions d'années à deviner. Allez plus vite et le serveur sera expulsé d'Internet pendant la durée de l'attaque, et l'administrateur système le remarquera / enquêtera.

Pour forcer efficacement un mot de passe à 10 caractères, vous avez besoin de centaines de milliards de suppositions par seconde, et cela prendra encore des semaines. Aucun serveur n'est capable de recevoir quoi que ce soit à distance proche de autant de tentatives de connexion SSH. Quelques centaines de tentatives par seconde sont plus réalistes, ce qui est trop lent pour être efficace à moins que le mot de passe soit terrible. Quiconque lit ce site Web est assez intelligent pour choisir un bon mot de passe.

@AbhiBeckert Je pense que vous confondez la taille des clés avec l'entropie. De plus, casser la clé ou le mot de passe ne doit pas toujours être une attaque en ligne: l'attaquant peut avoir accès à la clé publique. En tout cas, je pense que vous avez complètement manqué mon argument: l'entropie dans une paire de clés, à l'exception des [bogues] (https://www.schneier.com/blog/archives/2008/05/random_number_b.html), est toujours beaucoup plus grande que n'importe quel mot de passe mémorable.

@Gilles et je pense que vous manquez mon point, qui est que personne ne devrait utiliser des mots de passe mémorables pour un serveur de production. Les mots de passe doivent être des nombres aléatoires complets, encodés à l'aide de caractères pouvant être tapés sur un clavier.

Bruno

2011-05-17 20:16:45 UTC

view on stackexchange narkive permalink

Cela dépend des menaces que vous considérez.

Le principal objectif de l'authentification par clé publique / privée est de ne pas révéler votre secret, même à la partie à laquelle vous vous authentifiez. Pour cette raison, il est préférable d'utiliser des clés, car vous n'envoyez jamais votre secret hors de votre machine.

Cependant, si la menace que vous considérez est locale, et si vous ne protégez pas vos clés privées avec un mot de passe, stocker une liste de mots de passe en clair revient à peu près au même stockage des clés privées sans protection.

Pour cette raison, il est utile de protéger vos clés privées avec un mot de passe et d'utiliser des outils tels que ssh-agent (pour plus de commodité ). Sur OSX, cela peut également être intégré à KeyChain, de sorte que vous n'aurez peut-être même pas besoin de déverrouiller la clé privée (au niveau de l'application, uniquement au niveau du démon de sécurité) pour pouvoir l'utiliser via SSH (essentiellement, le KeyChain et le démon de sécurité s'occupent de ssh-agent).

> Le principal objectif de l'authentification par clé publique / privée est de ne pas révéler votre secret, même à la partie à laquelle vous vous authentifiez. Pour cette raison, il est préférable d'utiliser des clés, car vous n'envoyez jamais votre secret en dehors de votre machine. L'authentification par mot de passe par défi n'est-elle pas prise en charge par SSH?

Bienvenue sur Security.SE. Comme vous l'avez peut-être remarqué, vos réponses sont rejetées par divers membres de la communauté. Si vous avez une bonne lecture de la FAQ (lien en haut de la page), vous aurez une meilleure vue sur la façon de publier dans cette communauté. Vous voudrez peut-être aussi vous concentrer davantage sur les nouvelles questions plutôt que sur les anciennes avec des réponses hautement votées et acceptées.

... en outre, votre ajout ici en tant que réponse aurait été plus approprié à placer en tant que commentaire. Quant à votre question de clarification, SSH ne prend pas en charge l'authentification par défi de mot de passe.

Karol J. Piczak

2011-05-17 20:12:57 UTC

view on stackexchange narkive permalink

La principale différence entre l'utilisation d'une clé privée sans mot de passe et l'utilisation d'un mot de passe en texte brut pour l'autorisation SSH est l'autorisation par quelque chose que vous clé privée) ou par quelque chose que vous savez (votre mot de passe mémorisé). Ils sont de race différente, mais il est difficile de dire que l’une d’elles est finalement meilleure ou plus sûre.

L’autorisation par quelque chose que vous possédez est normalement plus difficile pour l’attaquant à répliquer depuis le bleu - il est plus facile de forcer / deviner votre mot de passe plus simple que de répliquer votre clé. Mais cela présente un inconvénient majeur: il est désormais primordial de garder votre clé privée vraiment secrète . Si vous utilisez quelque chose que vous seul connaissez (mot de passe mémorisé), il devrait être plus facile de le conserver (du moins en théorie). Mais si vous devez le mémoriser, alors vous utilisez probablement quelque chose qui n'est pas si complexe.

C'est donc à vous de décider, ce qui est plus probable - votre clé privée forte est volée ou un mot de passe pas si fort deviné (ou acquis d'une autre manière).

Il y a une exception ici - si vous voulez dire dans votre question que vous allez stocker des mots de passe très longs, complexes et aléatoires dans votre fichier secret au lieu d'utiliser une clé privée, alors il y a probablement ~~petite différence entre les deux~~ encore une certaine différence (j'ai manqué la partie, voir la réponse de @john pour un bel article à ce sujet ). Dans ce cas, les deux sont des types quelque chose que vous avez , gardez-le secret , mais ~~alors demandez-vous - pourquoi le faire en premier lieu si c'est ce que les clés privées ont été conçues pour?~~ vous devriez rester avec des clés privées dans ce cas.

Notez également que ces deux peuvent être combinés de manière simple en protégeant la clé privée par mot de passe. Vous avez maintenant besoin de quelque chose que vous * connaissez * (le mot de passe) pour accéder à quelque chose que vous * avez * (la clé privée).

sarnold

2011-06-13 06:10:02 UTC

view on stackexchange narkive permalink

Le document référencé traite des mots de passe saisis dans une session ssh; Je pense que cela, et les commentaires de Richard, valent la peine d'être gardés, mais je ne crois plus à la réponse elle-même. (Je préfère toujours les clés publiques.)

Song, Wagner et Tian ont montré qu'il est possible d'accélérer les recherches de mots de passe par force brute environ 50 fois par en utilisant les informations de synchronisation des sessions ssh . Noack a revisité leur étude et a trouvé SSH2 vulnérable à l'analyse temporelle.

L'attaque fait deux hypothèses:

Le hachage de mot de passe est disponible pour le craquage par force brute.
Un attaquant peut obtenir des horodatages précis sur les paquets envoyés entre les hôtes, ou acquérir des informations de synchronisation.

Les clés publiques sont non seulement plus pratiques, mais plus sécurisées contre certaines menaces.

Ce commentaire est trompeur et l'auteur a peut-être mal compris le travail de Song et al. Cela ne s'applique que si vous tapez votre mot de passe sur une connexion SSH, de manière interactive: par exemple, si vous utilisez SSH pour vous connecter à un hôte distant, exécutez une commande avec sudo afin que vous deviez taper votre mot de passe pour l'authentification sudo sur la connexion. Lorsque vous faites cela, les horaires inter-paquets de vos frappes au fur et à mesure que vous tapez le mot de passe révèlent des informations sur le mot de passe. [suite…]

La question, cependant, ne concerne pas «la saisie de votre mot de passe via SSH», mais plutôt «l'authentification par mot de passe SSH», qui est totalement indépendante. Lorsque vous vous authentifiez par mot de passe sur un serveur SSH (avec les méthodes userauth "password" ou "keyboard-interactive"), vous tapez votre mot de passe localement - pas via SSH. Le mot de passe est envoyé en un seul paquet au serveur. L'attaque chronométrée n'est pas pertinente ici.Voir: http://archive.oreilly.com/pub/a/linux/2001/11/08/ssh_keystroke.html

@RichardE.Silverman, merci. J'ai modifié ma réponse pour indiquer que j'ai mal lu ou mal me souvenu du document. (Je ne me souviens plus maintenant, c'était il y a très longtemps.)

martin

2011-06-12 20:11:15 UTC

view on stackexchange narkive permalink

Si vous utilisez des clés "logicielles" (c'est-à-dire des clés stockées dans votre répertoire .ssh ou équivalent), vous êtes fondamentalement au même niveau que le stockage des mots de passe.

OpenSSH a maintenant un support PKCS # 11 presque correct, il en est de même dans KiTTY (un fork de PuTTY) donc pour vraiment utiliser l'authentification pubkey, optez pour une carte à puce. Ensuite, il y a une réelle différence avec les mots de passe. Un fichier de clé logicielle, protégé par un mot de passe, peut être répliqué de la même manière qu'un mot de passe simple, contrairement à une carte à puce.

Comme le notent les autres réponses, il existe de nombreux scénarios dans lesquels pk auth est une protection très efficace, vous devez donc au moins clarifier les scénarios de menaces que vous abordez.

Si votre hôte est compromis par l'adversaire (autre que perdu / volé, ce qui signifie que vous êtes piraté / rooté / keylogged etc.) vos clés privées protégées par un mot de passe sont aussi bonnes que de simples mots de passe simples qui sont reniflés - les deux peuvent être copiés et utilisés sans votre consentement. En revanche, le clonage d'une carte à puce s'est avéré «assez difficile» pour de simples mortels comme nous. En outre, la destruction d'une carte à puce détruit généralement la clé privée, la suppression d'une copie d'un fichier que vous avez ne signifie pas qu'il existe d'autres copies «quelque part»

Sûr. Mais vous ignorez la protection que même le logiciel pk auth vous offre contre la perte de votre mot de passe au profit de l'hôte distant (pour une éventuelle réutilisation sur d'autres hôtes où vous l'avez réutilisé, comme tant de gens le font), ou à un MITM, comme d'autres ont souligné.

Peut être. Mais j'espère avoir également attiré l'attention sur les problèmes liés à l'authentification par clé (protégée par mot de passe uniquement).