Pourquoi les clés PGP et SSH ne voient-elles pas une utilisation plus répandue comme deuxième facteur lors de l'authentification?
U2F, qui repose sur un premier échange de clés et un mécanisme de réponse aux défis, est l'une des principales méthodes MFA émergentes.
C'est un protocole relativement nouveau et commence seulement à voir une adoption plus répandue, notamment parmi les grandes entités Web comme Google, mais ce n'est pas le premier mécanisme facile à utiliser, à échange de clés et à réponse aux défis; en fait, deux me viennent à l'esprit assez facilement:
SSH, qui existe depuis 1995 et est disponible sur pratiquement tous les boîtiers Linux et BSD mis en place depuis 2000, avec une adoption croissante sur Windows via des logiciels complémentaires dans les anciennes versions et des logiciels intégrés dans les versions plus récentes; et
PGP, qui existe depuis 1991, et est en fait inclus sur certains des Yubikeys les plus récents (bien que, de manière controversée, avec une implémentation de source fermée dans la dernière génération), ainsi que sur des millions de PC dans le monde entier, avec de nombreuses implémentations et bibliothèques de haute qualité et activement entretenues pour une multitude d'OS.
Il semble qu'il serait parfaitement logique d'utiliser l'un ou l'autre de ces protocoles/normes largement disponibles (respectivement) en tant que mécanisme MFA pour plus que la simple connexion SSH dans une machine distante ou le cryptage des e-mails; alors pourquoi n'a-t-il pas non plus gagné en traction là où U2F est en plein essor?
Voyons ce que PGP et SSH proposent réellement à cet effet:
- PGP:
Le client doit installer le logiciel PGP qui n'est pas installé par défaut dans la plupart des systèmes. Le client doit créer une paire de clés PGP. Il doit ensuite envoyer la clé publique au serveur afin que le serveur puisse l'utiliser ultérieurement pour la validation. Lors de l'authentification avec 2FA, le serveur enverra un défi que le client doit signer avec sa clé privée et renvoyer le défi signé en réponse. Bien sûr, le client doit protéger sa clé contre le vol, peut-être avec un mot de passe. - SSH:
Le client doit installer le logiciel SSH qui n'est pas installé par défaut dans la plupart des systèmes. Doit créer une paire de clés et envoyer la partie publique au serveur. Lors de l'authentification avec 2FA contre un service Web, le client doit créer une connexion SSH vers un serveur associé et le serveur doit fusionner l'authentification réussie en utilisant SSH et la connexion au site Web d'une manière ou d'une autre, peut-être avec un jeton supplémentaire que le client doit donner après avoir utilisé SSH. Et oups, il peut y avoir un pare-feu dans la manière de bloquer SSH. Et bien sûr, le client doit protéger la clé contre le vol.
Ainsi, les deux solutions se résument essentiellement à:
- installer initialement certains logiciels
- créer une paire de clés statiques et publier la partie publique (cela peut être intégré dans le logiciel pour plus de commodité, mais ce n'est pas le cas actuellement)
- obtenir un défi du serveur et renvoyer le défi signé. Et en quelque sorte, le serveur doit intégrer la validation du défi dans le processus d'authentification. "en quelque sorte" car il n'y a pas de processus déjà établi pour cela qui intègre tout avec le flux d'authentification utilisé dans les applications web.
- et bien sûr le client doit protéger sa clé
La même procédure peut être beaucoup plus simple avec un certificat TLS du site client. Cela laisse toujours la création du certificat comme un problème majeur (mais cela est également possible dans le navigateur aujourd'hui) mais au moins la validation est déjà intégrée dans le protocole HTTPS.
De plus, je ne vois pas comment ces solutions offrent une meilleure expérience utilisateur ou expérience d'intégration que les solutions 2FA existantes. Ils sont pas faciles à utiliser, nécessitent des logiciels supplémentaires, nécessitent de nouvelles façons de s'intégrer avec le côté serveur, etc. Et ils n'offrent pas une meilleure sécurité non plus. Alors pourquoi faire attention et ne pas prendre en compte les nouvelles solutions conçues avec la convivialité et l'intégration du serveur à l'esprit?
En dehors de cela, les solutions 2FA bon marché actuelles utilisent un téléphone mobile. Ceux-ci fournissent généralement une meilleure architecture de sécurité que les PC actuels. Et il s'agit d'un périphérique matériel supplémentaire auquel l'utilisateur doit avoir accès, ce qui renforce la protection offerte par 2FA.
Manque de portabilité
SSH et PGP sont largement utilisés, mais ce ne sont pas des technologies Web. Il existe une technologie Web équivalente depuis de nombreuses années: les certificats clients SSL. Cependant, ce n'est pas très utilisé.
La raison en est le manque de portabilité. Si vous avez un certificat client SSL sur votre bureau à domicile, il est difficile de le déplacer ailleurs. Vous ne pouvez donc pas vous connecter à partir de votre ordinateur portable de travail, du bureau de votre belle-mère, etc.
Il existe une solution de certificat client portable qui existe depuis longtemps et qui est de très haute sécurité: les cartes à puce. La clé privée est stockée dans la carte à puce et n'est jamais libérée. Cependant, cela a surtout été utilisé dans des applications de haute sécurité, telles que les services bancaires en ligne aux entreprises.
Au début des années 2000, l'innovation était limitée en matière d'authentification. Les efforts visant le marché de masse, comme Microsoft Passport et OpenID, n'ont pas vraiment décollé. La plupart des produits étaient destinés au haut de gamme: accès VPN d'entreprise, etc. Cela est en train de changer et nous assistons à une innovation dans l'authentification grand public. Par exemple:
Mozilla persona - Rend essentiellement un certificat client portable en le stockant dans le cloud. Il y a des années, cela aurait été rejeté comme une idée folle, mais ces derniers temps, le modèle de menace est mieux compris et les avantages sont évidents.
2F - Apporte la haute sécurité des cartes à puce sur le marché de masse. Les appareils sont plus portables et il est sûr d'utiliser un appareil sur de nombreux sites Web différents. U2F est donc une technologie qui s'adapte parfaitement aux modèles d'utilisation modernes - d'où son succès.
Parce que les facteurs d'authentification supplémentaires devraient, idéalement, être hors bande. Comme un téléphone, un jeton ou une sorte de message télépathique.
U2F est bon car vous NE POUVEZ PAS extraire la clé privée et il nécessite une touche physique à l'appareil avant qu'il ne signe.
Pour le grand public, toute authentification à 2 facteurs doit être comprise en moins de 2 minutes, sinon elle échouera très rapidement car peu de gens pourront la comprendre. Cela nécessite généralement d'utiliser quelque chose que les gens connaissent déjà ou qui est très simple.
PGP et SSH sont des technologies complexes que très peu de gens, à l'exception des développeurs et des opérations informatiques, comprennent. Comme le souligne Stephen, les deux nécessitent non seulement l'installation du logiciel, mais la compréhension de méthodes très complexes de génération de fichiers, leur envoi à un tiers et (pire encore) la compréhension des concepts sous-jacents impliqués. Pour la personne moyenne, cela prendrait de nombreuses heures de formation, d'essais et d'erreurs, et des concepts entièrement nouveaux. Même alors, vous auriez des taux d'échec élevés.
Comparez cela avec les solutions utilisées en 2 facteurs. Messages texte, jetons durs qui affichent des numéros ou appels téléphoniques. Les SMS et les appels téléphoniques sont des choses que les gens connaissent déjà. Un jeton dur est légèrement plus complexe, mais un utilisateur peut être formé en moins de 2 minutes à l'utilisation de ces appareils car ils sont simples.
Le plugin EnigForm FireFox était une approche très prometteuse. Et en combinaison avec une SmartCard OpenPGP, elle était au moins aussi sécurisée que FIDO U2FA. C'est dommage qu'il n'ait pas été largement adopté.
Deux choses.
1. C'est comme ça que ça a toujours été
La biométrie ou les jetons matériels (tels que RSA SecurID) étaient la norme pour 2FA, puis tout le monde a obtenu des téléphones portables et plus tard des téléphones intelligents. Du coup, il a été facile de créer un deuxième facteur en envoyant aux gens un e-mail vers leur smartphone, ou vers une application sur leur smartphone, ou un sms vers des téléphones plus anciens.
Le fait que vous puissiez utiliser un cryptage à clé publique à la place n'a pas été considéré comme un deuxième facteur, car vous utilisiez généralement des clés publiques au lieu d'un mot de passe. C'était la perception des gens, et pour être honnête, je n'y avais pas trop pensé jusqu'à présent.
2. C'est moins sûr
Alors qu'un message à une application est déjà plus facilement intercepté que le RSA SecurID (ou Yubikey ou un autre jeton matériel) et donc moins sécurisé, l'utilisation de l'authentification par clé publique est probablement encore moins sécurisée que cela:
Un jeton peut être intercepté lorsque vous le tapez, mais votre clé privée peut être volée une fois pour toutes. La source du deuxième facteur n'est pas sur un serveur (envoi de messages texte) ou cachée dans un module inviolable (un jeton), c'est dans le système que vous utilisez tout le temps pour beaucoup de choses.
(Il faut noter que les cartes à puce résolvent ce problème, mais alors, je connais vraiment peu de gens qui utilisent cela en dehors du travail.)
De plus, la plupart des autres réponses incluent "personne n'a cela" sous une forme ou une autre, et elles ont raison. Mais la plupart des gens n'utilisent pas non plus 2FA. Je pense que le chevauchement entre les techniciens qui utilisent SSH et/ou PGP et 2FA est significatif, infirmant l'argument selon lequel personne n'utilise SSH, PGP ou quelque chose de similaire. Surtout des endroits comme Github pourraient totalement offrir SSH comme deuxième facteur; ils prennent déjà en charge les clés SSH (et les gens l'utilisent! ), mais pas pour 2FA.