1. Les utilisateurs sont stupides

Un mot de passe est quelque chose qui tient dans la mémoire d'un utilisateur, et l'utilisateur le choisit. Étant donné que l'authentification consiste à vérifier l'identité physique de l'utilisateur à distance (du point de vue du vérificateur), le comportement de l'utilisateur est nécessairement impliqué dans le processus - cependant, les mots de passe dépendent de la partie de l'utilisateur qui est le plus notoirement médiocre dans la gestion de la sécurité, à savoir son cerveau. Les utilisateurs ne comprennent tout simplement pas ce qu'est l'entropie de mot de passe. Je ne leur blâme pas cela: il s’agit d’un sujet technique, d’une spécialisation, qui ne peut devenir de sitôt du «bon sens». D'un autre côté, la sécurité d'un jeton physique est beaucoup plus «tangible» et les utilisateurs moyens peuvent devenir assez bons dans ce domaine. Les évolutionnistes diraient que les humains ont été sélectionnés pour cela au cours du dernier million d'années, parce que ceux qui ne pouvaient pas conserver leurs outils en silex n'ont pas survécu suffisamment pour avoir une progéniture.

Les films hollywoodiens peuvent être utilisés comme modèle de la façon dont les utilisateurs pensent aux mots de passe - ne serait-ce que parce que ces utilisateurs vont également au cinéma Invariablement, l'Arch Enemy a un mot de passe court et adore s'en vanter et distribue des indices chaque fois qu'il le peut. Et, invariablement, un agent secret britannique devine le mot de passe à temps pour désactiver la bombe à fusion qui a été plantée sous le parterre de fleurs préféré de la reine. Les films projettent une réalité déformée et exagérée, mais ils représentent toujours la base mentale sur laquelle les utilisateurs moyens opèrent: ils envisagent les mots de passe comme assurant la sécurité en étant plus «spirituels» que l'attaquant. Et, invariablement, la plupart y échouent.

La "force du mot de passe" peut être quelque peu améliorée par des règles obligatoires (au moins huit caractères, au moins deux chiffres, au moins une majuscule et une lettre minuscule ...) mais ces règles sont perçues comme un fardeau par les utilisateurs, et parfois comme une contrainte insupportable sur leur liberté innée - de sorte que les utilisateurs deviennent à combattre les règles, avec une grande créativité, en commençant par l'écriture traditionnelle du mot de passe sur une note autocollante. Plus souvent qu'autrement, les règles de renforcement des mots de passe se retournent contre eux.

D'un autre côté, les certificats d'utilisateur impliquent un système de stockage, et si ce système est un appareil physique que l'utilisateur transporte avec ses clés de maison ou de voiture , alors la sécurité dépend (en partie) de la façon dont l'utilisateur moyen gère la sécurité d'un objet physique, et il fait généralement du bon travail. Au moins mieux que lorsqu'il s'agit de choisir un bon mot de passe. C'est donc un gros avantage des certificats.

2. Les certificats utilisent la cryptographie asymétrique

L '«asymétrie» concerne la séparation des rôles. Avec un mot de passe, quiconque vérifie le mot de passe connaît à un moment donné le mot de passe ou une donnée équivalente au mot de passe (enfin, ce n'est pas tout à fait vrai dans le cas des protocoles PAKE). Avec les certificats utilisateurs, le certificat est émis par une autorité de certification, qui garantit le lien entre une identité physique et une clé publique cryptographique. Le vérificateur peut être une entité distincte , et peut vérifier un tel lien et l'utiliser pour authentifier l'utilisateur, sans avoir la possibilité de se faire passer pour l'utilisateur.

En un mot, c'est le but des certificats: séparer ceux qui définissent l'identité numérique de l'utilisateur (c'est-à-dire l'entité qui fait le mappage de l'identité physique au monde informatique) de ceux qui authentifier les utilisateurs.

Cela ouvre la voie aux signatures numériques qui apportent la non-répudiation. Cela intéresse particulièrement les banques qui prennent les commandes financières des clients en ligne: elles doivent authentifier les clients (c'est de l'argent dont nous parlons, une affaire très sérieuse) mais elles aimeraient avoir une trace convaincante des commandes - dans le sens de: a le juge serait convaincu. Avec une simple authentification, la banque a l'assurance de parler au bon client, mais elle ne peut pas le prouver à des tiers; la banque pourrait créer une fausse transcription de connexion, elle est donc sans armes contre un client qui prétend être accusé par la banque elle-même. Les signatures numériques ne sont pas immédiatement disponibles même si l'utilisateur dispose d'un certificat; mais si l'utilisateur peut utiliser un certificat pour l'authentification, la plupart du travail acharné a été effectué.

De plus, les mots de passe sont intrinsèquement vulnérables aux attaques de phishing, contrairement aux certificats d'utilisateurs. Précisément à cause de l'asymétrie: l'utilisation du certificat n'implique jamais de révéler des données secrètes au pair, donc un attaquant qui se fait passer pour le serveur ne peut rien apprendre de valeur de cette façon.

3. Les certificats sont complexes

Le déploiement de certificats utilisateur est complexe, donc coûteux:

• L'émission et la gestion des certificats est un véritable ver, comme toute PKI le vendeur peut vous le dire (et, en effet, je vous le dis). Surtout la gestion des révocations. PKI est d'environ 5% de cryptographie et 95% de procédures. Cela peut être fait, mais pas à moindre coût.

• Les certificats utilisateur impliquent que les utilisateurs stockent leur clé privée d'une manière ou d'une autre, sous leur "accès exclusif". Cela se fait soit dans le logiciel (les systèmes d'exploitation existants et / ou les navigateurs Web peuvent le faire) soit en utilisant du matériel dédié, mais les deux solutions ont leur propre ensemble de problèmes d'utilisabilité. Les deux principaux problèmes qui se poseront sont 1) l'utilisateur perd sa clé, et 2) un attaquant obtient une copie de la clé. Le stockage logiciel fait de la perte de clé un problème plausible (à la merci d'un disque dur défaillant), et le partage de la clé entre plusieurs systèmes (par exemple, un ordinateur de bureau et un iPad) implique certaines opérations manuelles qui sont peu susceptibles d'être bien protégées contre les attaquants. Les jetons matériels impliquent toute l'activité compliquée des pilotes de périphériques, ce qui peut être encore pire.

• Un certificat utilisateur implique des opérations mathématiques relativement complexes côté client; ce n'est pas un problème même pour un Pentium II anémique, mais vous ne pourrez pas utiliser les certificats de certains Javascript giflés dans un site Web générique. Le certificat nécessite une coopération active de la part du logiciel côté client, et ledit logiciel a tendance à être, disons, sous-optimal sur le plan ergonomique à cet égard. Les utilisateurs moyens peuvent normalement apprendre à utiliser des certificats clients pour une connexion HTTPS à un site Web, mais au prix d'apprendre à ignorer la fenêtre contextuelle d'avertissement occasionnelle, ce qui les rend beaucoup plus vulnérables à certaines attaques (par exemple, les attaques actives où l'attaquant tente de leur donner son propre faux certificat de serveur).

D'un autre côté, l'authentification par mot de passe est vraiment facile à intégrer à peu près partout. Il est tout aussi facile de gâcher, bien sûr; mais au moins cela n'entraîne pas nécessairement des coûts supplémentaires incompressibles.

Résumé

Les certificats utilisateur permettent une séparation des rôles que les mots de passe ne peuvent pas faire. Ils le font au détriment de l'ajout d'une horde de problèmes de mise en œuvre et de déploiement, ce qui les rend coûteux. Cependant, les mots de passe restent bon marché en s'inscrivant dans un esprit humain, ce qui implique intrinsèquement une faible sécurité. Les problèmes de sécurité avec les mots de passe peuvent être quelque peu atténués par certaines supercheries (jusqu'à un protocole PAKE inclus) et, surtout, en blâmant l'utilisateur en cas de problème (nous savons que l'utilisateur moyen ne peut pas choisir un mot de passe sécurisé, mais tout incident sera être toujours de sa faute - c'est ainsi que les banques le font).

• Pro : Facile à déployer - il suffit d'un peu de code et d'un magasin de données sécurisé Selon la politique de sécurité, peut générer automatiquement des mots de passe ou forcer de nouveaux utilisateurs à les créer.

• Pro : Facile à administrer - les réinitialisations de mot de passe peuvent (pour certains politiques de sécurité) être fait avec des outils automatisés

• Con : pour une bonne sécurité, les mots de passe doivent être réinitialisés tôt et souvent. L'oubli ou le défaut de changer les mots de passe de l'utilisateur est soit un risque de sécurité, soit un problème d'utilisation.

• Contre : les bons mots de passe peuvent être difficiles à retenir, ce qui conduit aux problèmes des utilisateurs qui réutilisent les mots de passe ou les écrivent.

• Contre : les magasins de données de mots de passe sont un point faible - si un intrus obtient le magasin de mots de passe , il obtient la charge mère.

• Contre : Toutes les parties de la transmission de mot de passe peuvent conduire à une exposition - sites Web qui stockent les mots de passe localement pour faciliter l'utilisation, en interne composants de serveur qui transmettent en clair, les fichiers journaux dans les produits COTS qui stockent les mots de passe en clair. Le secret faisant partie de la transmission, vous êtes aussi fort que votre maillon le plus faible - cela demande un effort sérieux pour éviter l'exposition et l'exigence incombe à la fois à l'utilisateur et au développeur du système.

Certificats:

• Pro : ne nécessite pas la transmission du secret. La preuve de la clé privée ne contient aucune information secrète - atténue toutes sortes de points faibles de stockage / transmission.

• Pro : émise par une partie de confiance (l'autorité de certification ) qui permet un système de gestion centralisé du statut de plusieurs applications. Si un certificat tourne mal, il peut être révoqué. La correction d'une rupture de mot de passe doit être effectuée séparément pour chaque système, sauf si un identifiant partagé est utilisé.

• Pro : le cas de non-répudiation est plus fort - dans la plupart des systèmes de mot de passe, la façon dont l'utilisateur est initialement authentifié avant la création du compte est assez faible et les mécanismes de réinitialisation du mot de passe peuvent offrir un autre facteur de déni plausible. Avec de nombreuses formes de délivrance de certificats, il est beaucoup plus difficile pour un utilisateur de dire que ce n'était pas eux. Attention - vous êtes toujours aussi performant que les politiques d'émission de votre autorité de certification.

• Pro : sert plus que la simple authentification - peut assurer l'intégrité et la confidentialité

• Con : nécessite toujours un mot de passe / code PIN - presque tous les mécanismes de stockage de paires de clés privées sont ensuite déverrouillés avec un code PIN. Les cartes à puce peuvent avoir des capacités de protection contre les falsifications et de verrouillage pour empêcher la force brute, mais cela ne résout pas le fait que l'utilisateur a écrit son code PIN sur une note autocollante à côté de l'ordinateur où la carte est connectée. Parfois, les problèmes de mot de passe réapparaissent à plus petite échelle avec PKI.

• Contre : Complexité de l'infrastructure - la mise en place d'une PKI n'est pas une tâche facile et généralement si coûteuse tant pour le déploiement que pour la maintenance, il ne peut être utilisé que pour des systèmes volumineux / coûteux.

• Contre : les rapports sur l'état des certificats et les mises à jour ne sont pas faciles - révocation un identifiant utilisateur corrompu est onéreux en raison de la taille et de la complexité de l'infrastructure. Habituellement, une autorité de certification génère une liste de révocation de certificats qui peut ou non être provisionnée dans un serveur OCSP. Ensuite, chaque application doit vérifier chaque connexion pour le statut CRL ou OCSP. Cela introduit une variété de délais dans le système entre le moment où un identifiant PKI est signalé comme compromis et le moment où les systèmes qui s'appuient sur ce justificatif commencent réellement à refuser l'accès. La vitesse de mise à jour de l'état peut être accélérée, mais à un coût de complexité du système plus élevé.

Quelques autres remarques:

Un certificat devrait avoir une durée de vie plus courte et pouvoir être révoqué alors qu'un mot de passe durerait plus longtemps avant qu'une politique d'administration ne demande de le changer ...

I en désaccord avec la prémisse. Sur les systèmes sur lesquels j'ai travaillé qui prennent en charge les mots de passe et PKI, la politique relative aux exigences de mise à jour des mots de passe est BEAUCOUP plus courte que la politique d'émission de certificats. La révocation est une autre boîte de vers - c'est pour l'événement le moins probable de compromission de clé privée. Étant donné que les données de clé privée ne sont pas transmises via le système, le risque d'exposition à ces données est généralement supposé être bien inférieur au risque d'exposition au mot de passe. Pour des raisons pratiques, les mots de passe sont considérés comme ayant une durée de vie plus courte.

Je souhaite également savoir à quelles attaques ils sont sujets, par exemple comme mentionné jusqu'ici la force brute, alors que rien n'est mentionné pour les certificats ... qu'en est-il de XSRF?

Vous mélangez des pommes et des oranges ici. La force brutale peut être une attaque viable sur l'un ou l'autre type d'informations d'identification d'authentification - mais XSRF est une attaque contre un type d'application sous-jacent qui serait possible quel que soit le mécanisme d'authentification. À moins que vous ne vouliez dire que parce que le nom d'utilisateur / mot de passe serait entré avec une sorte d'interface texte, ils pourraient être sujets à des scripts intersites sur cette interface.

En général (excuses pour mon manque de terminologie officielle - je regarde généralement les termes d'attaque typiques mais je manque de temps):

• Force brute - parce que l'espace de clé de votre mot de passe moyen est plus petit que l'espace de clé d'une clé asymétrique, un mot de passe est plus facile à force brute. Cependant, une taille de clé suffisamment petite sur un certificat est également capable de force brute et la capacité d'attaquer les clés par force brute augmente avec les capacités du processeur, forçant une course effrénée avec l'augmentation de la taille des clés.

• Devinettes éclairées - réduire l'espace de clés à un ensemble raisonnable de suppositions est plus facile avec les mots de passe, et pas si évident pour la plupart des algorithmes de clé asymétrique, bien qu'il y ait des clés faibles dans l'algorithme RSA, il y a donc une certaine dépendance L'attaquant est un gros nerd de la cryptographie.

• Ingénierie sociale - faisable de toute façon, bien qu'avec un certificat stocké dans le matériel, vous devez non seulement contrôler le code PIN de l'utilisateur, mais aussi le matériel qui stocke leur clé.

• L'attaque interne - obtenir les informations d'identification de l'intérieur du système puis les utiliser pour émuler un utilisateur légitime - dépend. Si les mots de passe sont stockés de manière non sécurisée, c'est plus faisable pour un système basé sur un mot de passe. Mais si vous pouvez obtenir le contrôle de l'autorité de certification, vous pouvez vous émettre un certificat légitime et cela dépend de la façon dont l'accès est contrôlé.

• Homme au milieu - dépend - d'un homme au milieu peut intercepter un mot de passe si le mot de passe n'est pas crypté en transit par un mécanisme de cryptage qui le contourne. C'est faisable avec SSL / TLS. Cependant, un homme au milieu peut également intercepter des parties d'un transfert PKI, en fonction de la façon dont la PKI est utilisée. Les signatures PKI sans nonce ni horodatage sont ouvertes aux attaques de réplication par un homme du milieu - il peut renvoyer un message intercepté tant qu'il n'y a aucun moyen de savoir si le message est opportun ou unique.

1. Noms d'utilisateur et mots de passe
   
   • Tout dépend de ce que vous savez. Vous donnez un mot de code secret pour vous authentifier auprès du service.
   • Cela signifie que s'il est intercepté dans le flux, il peut être utilisé. L'utilisation du cryptage rend cela improbable mais toujours possible. Quelqu'un peut faire appel à un homme du milieu pour obtenir votre mot de passe ou prendre en charge l'authentification de l'ordinateur.
     
   • Un nom d'utilisateur et un mot de passe peuvent être utilisés sur n'importe quel ordinateur à tout moment. C'est une mauvaise chose si la sécurité est importante et une bonne chose si l'accessibilité compte. Pour une banque ... c'est mauvais. Pour Facebook, cela ne devrait vraiment pas avoir d'importance.
2. Certificats
   • Les certificats sont un peu plus sophistiqués. Le serveur envoie des données au client et le client signe les données et les renvoie. Cela signifie que le serveur ne connaît à aucun moment la clé privée, donc si un homme au milieu ou la prise de contrôle du serveur entraînera l’accès, il n’a pas votre clé.
   • Les certificats sont un douleur à utiliser. Vous ne vous en souvenez plus et ils peuvent être volés.

Le meilleur système est une combinaison. Vous mettez un mot de passe sur la clé afin d'avoir une authentification à deux facteurs. Quelque chose que vous connaissez (mot de passe), et quelque chose que vous avez (clé). Cependant, plus il y a de niveaux de sécurité, plus c'est douloureux. C'est le grand compromis en matière de sécurité.

Je suis d'accord avec les arguments de Stephen. Vous présentez une question difficile à rechercher, car le problème n'est généralement pas une comparaison de l'un par rapport à l'autre. Un bon moyen de comprendre pourquoi les deux existent et ne sont généralement pas évalués l'un par rapport à l'autre est de se concentrer sur l'utilisation. Les certificats sont liés aux magasins de clés au niveau de la machine et sont donc parfaits pour l'authentification de machine à machine entre des machines spécifiques planifiées à l'avance. Les mots de passe sont très bien adaptés aux personnes car nous sommes mobiles et avons tendance à nous authentifier à partir de nombreux systèmes d'une manière difficile à prévoir à l'avance. Ainsi, les certificats sont généralement conçus pour l'authentification basée sur le matériel et les mots de passe sont bons pour l'authentification basée sur le wetware mobile. Une carte à puce est un excellent moyen d'ajouter une authentification basée sur un certificat à l'humain mobile et un autre facteur au processus.

Un mot de passe peut souvent être forcé brutalement et il peut être conçu socialement, car, comme son propriétaire doit le mémoriser, il est souvent beaucoup plus simple qu'une clé secrète.

Une clé privée (de force suffisante - pour RSA, 2048 ou 4096 bits) ne peut pas être forcé brutalement. La seule façon de s'authentifier auprès d'un système qui nécessite une authentification basée sur une clé publique est d'obtenir d'abord l'accès à un autre ordinateur pour obtenir la clé privée. Cela introduit un niveau supplémentaire de complexité à toute attaque. L'ingénierie sociale pour amener une personne à révéler son mot de passe n'aidera pas, puisque le mot de passe ne déchiffre que sa clé privée, plutôt que de lui accorder l'accès directement au système cible. L'ingénierie sociale permettant à une personne de révéler sa clé privée avec son mot de passe est probablement beaucoup plus difficile.

De plus, les mots de passe sont transmis sur le réseau de la machine de l'utilisateur au système que l'utilisateur souhaite utiliser . Les clés privées ne sont pas transmises sur le réseau, ni en clair ni en format crypté; seule la clé publique est transmise.

Vous semblez oublier qu'une page Web peut utiliser à la fois des certificats et des mots de passe. Si un utilisateur avec un certificat arrive, la porte s'ouvre. Et s'il n'a pas de certificat, il doit se connecter avec son nom et mot de passe comme toujours.

De cette manière, les utilisateurs intéressés obtiennent leur certificat, tous les autres le font à l'ancienne.

Je voudrais ajouter une option - Périphériques à mot de passe unique. Je suis d'accord avec ce que d'autres ont dit sur les avantages et les inconvénients des certificats et des mots de passe - les appareils OTP nécessitent certains composants back-end pour fonctionner, mais peuvent être intégrés sans trop de tracas à mon avis (Active Directory est un peu différent, mais les systèmes ne sont pas trop durs).

Une combinaison d'un mot de passe et d'un mot de passe à usage unique fonctionne très bien. Vous pouvez opter pour une solution plus simple comme un Yubikey avec un mot de passe (connexion USB ou NFC requise), ou un porte-clés à code affiché.

Les deux options sont faciles à ajouter aux opérations basées sur Linux. Si vous voulez le faire dans Active Directory, vous devrez acheter un logiciel pour gérer le code et l'installer sur chaque serveur AD. L'utilisateur entre alors l'OTP au début du champ mot de passe, puis son mot de passe habituel. Il est possible de développer votre propre module pour cela, mais à un coût prohibitif d'après ce que j'ai vu.