Authentification basée sur certificat vs authentification par nom d'utilisateur et mot de passe
Quels sont les avantages et les inconvénients de l'authentification par certificat par rapport à l'authentification par nom d'utilisateur et mot de passe? J'en connais certains, mais j'apprécierais une réponse structurée et détaillée.
MISE À JOUR
Je suis également intéressé à savoir à quelles attaques sont-ils 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? Un certificat devrait avoir une durée de vie plus courte et pouvoir être révoqué tandis qu'un mot de passe vivrait plus longtemps avant qu'une politique d'administration ne demande de le changer ...
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 du utilisateur qui est notoirement médiocre pour gérer la sécurité, à savoir son cerveau. Les utilisateurs ne comprennent tout simplement pas à quoi sert l'entropie des mots de passe. Je ne suis pas à blâmer pour cela: c'est un sujet technique, une spécialisation, qui ne peut pas de façon réaliste devenir "bon sens" de si tôt. 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 positivement pour cela au cours du dernier million d'années, car ceux qui ne pouvaient pas tenir leurs outils en silex n'ont pas survécu suffisamment pour avoir une progéniture.
Les films hollywoodiens peuvent être utilisés comme un modèle de la façon dont les utilisateurs pensent des mots de passe - ne serait-ce que parce que ces utilisateurs vont aussi 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é placé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 "plein d'esprit" que l'attaquant. Et, invariablement, la plupart é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 minuscule ...) mais ces règles sont perçues comme un fardeau par les utilisateurs, et parfois comme un contrainte insupportable sur leur liberté innée - de sorte que les utilisateurs deviennent pour combattre les règles, avec une grande créativité, en commençant par l'écriture traditionnelle du mot de passe sur une note collante. Le plus souvent, les règles de renforcement des mots de passe se retournent de cette façon.
D'un autre côté, les certificats 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, 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 ils font généralement du bon travail. Au moins mieux que quand il s'agit de choisir un bon mot de passe. C'est donc un gros avantage des certificats.
2. Les certificats utilisent une 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 des données équivalentes à un mot de passe (enfin, ce n'est pas entièrement 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é distinct, et peut vérifier un tel lien et l'utiliser pour authentifier l'utilisateur, sans obtenant la possibilité de se faire passer pour l'utilisateur.
En un mot, c'est là l'intérêt 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 utilisateurs.
Cela ouvre la voie à signatures numériques qui apportent la non-répudiation. Cela intéresse particulièrement les banques qui reçoivent des commandes financières de clients en ligne: elles doivent authentifier les clients (c'est de l'argent dont nous parlons, une question 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 obtient une certaine assurance qu'elle parle au bon client, mais elle ne peut pas le prouver à des tiers; la banque pourrait construire une fausse transcription de connexion, donc elle est sans arme contre un client qui prétend être encadré par la banque elle-même. Les signatures numériques ne sont pas immédiatement disponibles même si l'utilisateur a un certificat; mais si l'utilisateur peut utiliser un certificat pour l'authentification, la plupart du travail acharné a été fait.
De plus, les mots de passe sont intrinsèquement vulnérables aux attaques de phishing, contrairement aux certificats utilisateur. Précisément à cause de l'asymétrie: l'utilisation du certificat n'implique jamais la divulgation de données secrètes à l'homologue, donc un attaquant usurpant l'identité du 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 une boîte de ver complète, comme tout fournisseur d'ICP peut vous le dire (et, en fait, je vous le dis). Surtout la gestion de la révocation. L'ICP représente environ 5% de cryptographie et 95% de procédures. Cela peut être fait, mais pas à moindre coût.
Les certificats d'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 par 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'utilisation. 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 de logiciels fait de la perte de clés 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é désordonné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 de certificats provenant de Javascript giflé dans un site Web générique. Certificat requiert coopération active des logiciels côté client, et lesdits logiciels ont tendance à être, disons, ergonomiques sous-optimaux à 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 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 un peu partout. Il est tout aussi facile de gâcher, bien sûr; mais au moins cela n'implique 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 ruses (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 toujours de sa faute - c'est ainsi que les banques le font).
Nom d'utilisateur/Mot de passe
Pro: Facile à déployer - prend juste du code et 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 certaines politiques de sécurité) se faire 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 la non-modification des mots de passe par l'utilisateur est soit un risque pour la sécurité, soit un problème d'utilisation.
Con: Les bons mots de passe peuvent être difficiles à retenir, ce qui entraîne des problèmes pour les utilisateurs de réutiliser des mots de passe ou de les écrire.
Con: Les magasins de données de mot de passe sont un point faible - si un intrus obtient le magasin de mot de passe, il obtient la charge mère.
Con: Toutes les parties de la transmission des mots de passe peuvent entraîner une exposition - des sites Web qui stockent les mots de passe localement pour une facilité d'utilisation, des composants de serveur internes qui transmettent en clair, des fichiers journaux dans les produits COTS qui stockent les mots de passe en clair. Le secret faisant partie de la transmission, vous n'êtes aussi fort que votre maillon le plus faible - cela prend de sérieux efforts pour empêcher l'exposition et l'exigence concerne à la fois l'utilisateur et le développeur du système.
Certificats:
Pro: Ne nécessite pas la transmission du secret. La preuve de clé privée ne contient aucune information secrète - atténue toutes sortes de points faibles de stockage/transmission.
Pro: émis par une partie de confiance (l'AC) qui permet un système de gestion centralisé pour le statut sur plusieurs applications. Si un certificat se détériore, 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 ID 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'est pas lui. Attention - vous êtes toujours aussi bon que les politiques d'émission de votre CA.
Pro: sert plus que la simple authentification - peut également assurer l'intégrité et la confidentialité.
Con: nécessite toujours un mot de passe/code PIN - presque tout mécanisme de stockage de paire de clés privées est ensuite déverrouillé avec un code PIN. Les cartes à puce peuvent avoir des capacités de protection contre le sabotage et de verrouillage pour empêcher la force brute, mais cela ne résout pas le fait que l'utilisateur a écrit son PIN sur une note autocollante à côté de l'ordinateur où la carte est ancrée. Parfois les problèmes de mot de passe réapparaissent sur une plus petite échelle avec PKI.
Con: 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 en déploiement et en maintenance qu'elle ne peut être utilisée que pour des systèmes volumineux/coûteux.
Con: Les rapports et mises à jour sur l'état des certificats ne sont pas faciles - la révocation des informations d'identification d'un utilisateur qui sont corrompues est onéreuse 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 retards 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 cet identifiant commencent réellement à refuser l'accès. La vitesse de mise à jour du statut peut être accélérée, mais à un coût de complexité du système plus élevé.
Quelques autres notes:
On s'attend à ce qu'un certificat ait une durée de vie plus courte et puisse être révoqué tandis qu'un mot de passe vivrait plus longtemps avant qu'une politique d'administrateur demande de le changer ...
Je suis en désaccord avec la prémisse. Sur les systèmes sur lesquels j'ai travaillé qui prennent en charge à la fois le mot de passe et l'ICP, la politique concernant les exigences de mise à jour du mot de passe est BEAUCOUP plus courte que la politique d'émission de certificats. La révocation est une boîte de vers différente - 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 beaucoup plus faible que le risque d'exposition au mot de passe. À des fins pratiques, les mots de passe sont considérés comme ayant une durée de vie plus courte.
Je suis également intéressé à savoir à quelles attaques sont-ils 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 brute peut être une attaque viable sur l'un ou l'autre type d'informations d'identification d'authentification - mais XSRF est une attaque sur un type d'application sous-jacent qui serait possible quel que soit le mécanisme d'authentification. À moins que vous ne vouliez dire que, comme le nom d'utilisateur/mot de passe serait entré avec une sorte d'interface de texte, ils pourraient être sujets à des scripts intersites sur cette interface.
En général (excuses pour mon manque de terminologie officielle - je recherche 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 à forcer brutalement. Cependant, une taille de clé suffisamment petite sur un certificat est également compatible avec la force brute et la capacité de clés d'attaque par force brute augmente avec les capacités du processeur forçant une course de rats avec une taille de clé augmentée.
Deviner instruit - 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és asymétriques, bien qu'il y ait des clés faibles dans l'algorithme RSA, il y a donc une certaine dépendance sur la taille d'un gros nerd crypto l'attaquant est.
Ingénierie sociale - réalisable dans les deux cas, bien qu'avec un certificat stocké dans le matériel, vous devez non seulement contrôler le PIN) de l'utilisateur, mais aussi le matériel qui stocke sa 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, cela 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-même délivrer un certificat légitime et cela dépend de la façon dont l'accès est contrôlé.
L'homme au milieu - dépend - un homme au milieu peut intercepter un mot de passe si le mot de passe n'est pas chiffré en transit par un mécanisme de chiffrement qui le contourne. C'est faisable avec SSL/TLS. Cependant, un homme au milieu peut également intercepter des parties d'un transfert PKI, selon la façon dont la PKI est utilisée. Les signatures PKI sans nonce ou horodatage sont ouvertes aux attaques de réplication par un homme au milieu - il peut renvoyer un message intercepté tant qu'il n'y a aucun moyen de dire si le message est ponctuel ou unique.
- Noms d'utilisateur et mots de passe
- Tout dépend de ce que vous savez. Vous donnez un mot de passe 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 peu probable mais toujours possible. Quelqu'un peut faire un homme au milieu pour obtenir votre mot de passe ou reprendre l'ordinateur recevant l'authentification.
- Un nom d'utilisateur et un mot de passe peuvent être utilisés à tout moment sur n'importe quel ordinateur. C'est une mauvaise chose si la sécurité est importante et une bonne chose si l'accessibilité est importante. Pour une banque ... c'est mauvais. Pour Facebook, cela ne devrait vraiment pas avoir d'importance.
- 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 pas la clé privée à tout moment, alors qu'un homme au milieu ou une prise de contrôle du serveur entraînera leur accès, ils n'ont pas votre clé.
- Les certificats sont difficiles à utiliser. Vous ne vous en souvenez pas et ils peuvent être volés.
Le meilleur système est une combinaison. Vous mettez un mot de passe sur la clé pour 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 couches de sécurité, plus c'est pénible. C'est le grand compromis en matière de sécurité.
Je suis d'accord avec les points de Stephen. Vous posez 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 les uns par rapport aux autres 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 à s'authentifier à partir de nombreux systèmes d'une manière difficile à prévoir à l'avance. Ainsi, les certificats sont typiques d'une authentification basée sur le matériel conçue à l'avance et les mots de passe sont bons pour l'authentification basée sur le Web mobile. Une carte à puce est un excellent moyen d'ajouter une authentification basée sur un certificat à l'homme mobile et un autre facteur au processus.
Un mot de passe peut souvent être forcé par la force 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ée 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 de complexité supplémentaire à toute attaque. L'ingénierie sociale pour amener une personne à révéler son mot de passe n'aidera pas, car le mot de passe ne fait que déchiffrer sa clé privée, plutôt que de lui accorder l'accès direct au système cible. L'ingénierie sociale pour amener une personne à révéler sa clé privée avec son mot de passe sera 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 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 vient, la porte s'ouvre. Et s'il n'a pas de certificat, il doit toujours se connecter avec son nom et son mot de passe.
De cette façon, les utilisateurs intéressés obtiennent leur certificat, tous les autres le font à l'ancienne.
Je voudrais ajouter une option - Dispositifs à 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 périphériques OTP nécessitent certains composants principaux pour fonctionner, mais peuvent être intégrés sans trop de tracas à mon avis (Active Directory est un peu différent, mais d'autres 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 (USB ou NFC requise), ou un code fob 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 par rapport à ce que j'ai vu.