Une authentification par mot de passe sur le web est vite problématique. Avec la multiplication des sites web, chacun avec son compte, on a vite fait d’utiliser le même mot de passe pour un même type de site, voire le même mot de passe partout. Tôt où tard on finit par s’authentifier sur une machine publique, chez un voisin, sur un wifi public, ou alors un des services finit par avoir une faille de sécurité, voire quelqu’un a posé un spyware sur notre machine habituelle.
Problématique simple : Je veux que personne ne puisse s’authentifier sur mes comptes frauduleusement, et le mot de passe n’est pas la solution.
Mots de passes uniques
Palliatif simple : Je génère un mot de passe par site. Je l’ai fait un temps, mais on atteint vite les limite de ce qu’on peut retenir de tête, même en utilisant une astuce pour déterminer le mot de passe en fonction du site (genre faire changer une partie du mot de passe en fonction du site). Au final la facilité reprend le dessus et on utilise trop souvent le même, ou des trop proches.
C’est encore plus vrai pour les mots de passe « sensibles » (comptes mails principaux, machines perso, machine pro) où le mot de passe devrait être complexe, différent à chaque fois, et renouvelé au minimum à chaque changement de société ou de prestataire. Jusqu’à quatre mots de passe forts c’est encore gérable, après ça devient ingérable, surtout si certains sont peu utilisés (donc vite oubliés).
Générateurs automatiques de mots de passe
Dans la même lignée on peut utiliser un système automatique pour générer un mot de passe à partir du nom ou de l’URL du service, ou aléatoirement en tenant à jour une liste de mots de passe. C’est mieux, mais on reste dépendant de cet algorithme. Si je suis à l’extérieur, je risque de ne plus y avoir accès. Ensuite ça ne pallie qu’une partie du problème : ça n’empêche pas le mot de passe de se diffuser, et d’être utilisé frauduleusement par un tiers. Ça limite juste les dégâts si c’est le service tiers qui a un problème de sécurité.
OpenID
OpenID c’est une manière de résoudre le problème par l’autre bout. On centralise la gestion de l’authentification sur un seul site, et tous peuvent ensuite y faire appel. Du coup je n’ai aucun seul mot de passe à retenir : celui de mon compte openid. Je peux faire en sorte qu’il soit complexe, transmis sur une connexion sécurisée, et je ne crains pas les failles applicatives des services tiers.
Ça résout certaines questions, mais en pose d’autres : Comment est-ce que je m’authentifie sur le serveur OpenId ? si c’est un mot de passe alors j’ai un risque d’autant plus grand s’il est découvert. Tous mes services en dépendent.
RSA SecurID
SecurID c’est le système classique en entreprise. On vous donne une sorte de porte clef personnel qui génère un mot de passe unique toutes les 15 secondes. Naturellement chaque porte clef est initialisé différemment donc seul le votre donne accès à votre compte. Le mot de passe est à usage unique, et totalement sans intérêt passé une minute. Les risques d’accès frauduleux sont donc fortement limités.
Malheureusement ça ne semble pas vraiment convenir à un usage personnel courant. Tout d’abord je n’ai qu’un seul support physique, et aucun accès de secours. Si je perds mon accès, je dois me reposer sur un administrateur tiers qui me redonne un nouveau support et le lie à mon compte.
En vacances, ou simplement si je n’ai pas ma veste avec moi, il peut arriver que je n’ai pas mon support. Sous réserve que je considère mon accès comme « sans risques » je souhaite pouvoir passer sans le jeton d’authentification forte. Là je n’avais pas ce choix.
Ensuite le jeton repose sur un système de clefs et de secrets qui est détenu par Verisign. C’est un point qui est sensible pour moi, d’autant qu’il y a eu une faille chez eux récemment et qu’on se demande si les secrets n’ont pas été divulgués. Un système open source sans serveur tiers me semble indispensable.
Enfin, pour éviter qu’il suffise de voler le porte clef plastique pour avoir accès à mon compte, je devais ajouter un PIN de quatre chiffres. Ce qui m’étonne c’est que ce PIN n’est pas à saisir sur le porte clef, mais à côté du jeton d’authentification, dans le formulaire web. Quiconque regarde mon clavier, écoute sur le réseau, ou a réussi à poser un spyware sur ma machine connaitra ce PIN. Bref, il n’est pas si secret que ça.
Pour ma société, voire pour l’accès à mon compte en banque (et encore), pourquoi pas. Pour le reste, bof bof.
Google 2 steps verification
Le système Google est pour moi un peu plus souple déjà. Il utilise une application sur mon smartphone et pas un porte clef tiers mais le système semble similaire. Ca n’a l’air de rien mais le téléphone a beaucoup plus de chances d’être avec moi. Il intervient après l’authentification par mot de passe (d’où le nom de « deux étapes ») et on peut forcer la seconde étape à ne pas être redemandée à chaque fois pour la même machine qu’on sait « sûre ».
Pour autant je ne suis pas toujours avec mon téléphone, et il peut tomber hors batterie. Dans ces conditions, et si j’ai confiance dans le poste et la connexion sur lesquels je suis, j’aurai aimé pouvoir saisir un mot de passe spécifique qui zappe l’authentification forte. Ça fonctionne tant que c’est exceptionnel mais Google ne me le propose pas. Google me propose par contre de générer une série de mots de passe à usage unique. Malheureusement l’usage unique est potentiellement gênant et surtout ça implique de les noter quelque part, avec le risque de les perdre ou de se les faire voler. Bref, on peut mieux faire même si j’apprécie l’intention.
Pour ne pas risquer de perdre des accès et comme il n’y a pas d’administrateur humain tiers, je peux proposer à Google un second numéro de téléphone qui sert en backup, si jamais je perds le premier. Là aussi c’est positif. Maintenant personnellement j’ai un téléphone perso, un de boulot, je risque parfois d’avoir l’un et pas l’autre. J’aurai aimé autoriser les deux à me servir pour l’authentification forte et ce n’est pas proposé.
Point positif, google garde une compatibilité avec toutes les applications qui continuent à utiliser un simple mot de passe comme interface. Je peux faire générer autant de mot de passe que je veux (ils sont longs et complexes) et les affecter à des applications. J’ai ensuite la liste des applications dans mon interface d’administration et je peux en ajouter ou en retirer à la volée. Le résultat c’est que je peux valider ou refuser chaque application indépendamment, sans secret partagé entre toutes.
Côté sécurité, rien ne m’indique qu’il est impossible de copier le logiciel présent sur mon téléphone portable (ou les mots de passe à usage unique que j’ai en backup) et l’utiliser sans que je ne le sache. Techniquement ça ne prend pas longtemps pour quelqu’un qui a accès à mon téléphone, 10 minutes au plus. J’aurai aimé un système qui détecte que deux téléphones distincts utilisent la même clef et me l’indique. Si c’est présent Google n’en parle pas.
Enfin, tout ça est « google-only ». Je peux certes utiliser google en openid, mais ça reste centralisé. J’aurai aimé quelque chose d’utilisable partout, y compris sur mes serveurs.
Clefs SSH
En rédigeant tout ça je me suis rendu compte que j’utilisais déjà un système assez ressemblant : les clefs SSH. Pour me connecter à mes serveurs j’utilise des clefs privées. J’ai une clef par source, toutes différentes. Je peux autoriser facilement une nouvelle source, ou en griller une existante, sans mettre à jour. J’ai aussi un mot de passe de secours que je peux utiliser quand je suis à l’extérieur.
Malheureusement là c’est uniquement pour ssh, et mes authentifications se font à 90% sur des formulaires web. Ca demande aussi d’avoir ses clefs ssh sur soi, or le scénario d’authentification forte est surtout utile justement quand je suis ailleurs que chez moi, ou avec une machine qui n’est pas une machine de confiance.
Je n’ai non plus aucun système qui m’assure que ma clef n’a pas été copiée et utilisée par un tiers.
Et vous ? Qu’avez-vous pour vos authentifications fortes ?
En regardant j’aimerai :
- Authentification par un système de clefs privée/publique géré par une appli sur mon téléphone portable
- Possibilité de gérer une liste de clefs autorisées (une par téléphone portable) pour ajouter/retirer facilement un accès
- Le jeton renvoyé par le téléphone est obtenu par une combinaison d’un mot de passe ou PIN et de la clef (il faut les deux, et donc le mot de passe n’est pas saisit sur le PC public mais sur mon propre téléphone)
- Un système de numéro incrémental est associé au jeton d’accès afin de repérer si un tiers utilise une de mes clefs après l’avoir copiée (si le numéro est égal ou plus faible que la dernière fois le serveur refuse l’accès, je saurai donc que quelqu’un utilise ma clef ailleurs et je pourrai la supprimer des autorisations)
- Authentification alternative par un mot de passe que je choisis moi, pour quand je n’ai pas mes téléphones et que je suis prêt à prendre le risque
- Authentification alternative par mot de passe pour les API, logiciels, etc. (mot de passe généré, long/complexe)
- Possibilité de gérer une liste de mots de passe autorisés (un par application/API) pour ajouter/retirer facilement un accès
15 réponses à “Authentification forte”
A solutions égales (par exemple multi-facteurs, comme un « ce que je sais » et un « ce que j’ai »), quand un des facteurs est le secret (mon mot de passe), j’ai tendance à faire appel systématiquement à SFSP
http://www.sans.org/reading_ro…
En gros, mon réel secret, c’est la méthode que j’utilise pour générer mes mots de passe, pas les mots de passe eux même.
Au début on tatonne, mais après ça devient vraiment amusant à utiliser (exemple de paramètres à la con que tu peux mettre en input : la couleur de la mire de login, le pseudo de la personne qui t’a invité sur un service, etc)
Avant de me poser la question de comment j’accède à mes données, je regarde qui les stocke et si le stockage est crypté, c’est là la faille principale. La deuxième faille c’est le social engineering. Au final, pour les données réellement intéressantes, c’est du bon vieux X.509 avec clef privée protégée par mot de passe fort. Pour le reste, s’il y a des personnes assez bêtes pour pirater mon compte Twitter, c’est pas bien grave :-)
On reste alors dans un système à multiples mots de passe. Un spyware, un wifi public, une machine pas si « de confiance » qu’on ne l’imaginais, ça peut poser problème, or c’est un des cas principaux que je souhaite éliminer.
On se retrouve alors assez proche de ma section pour les clefs SSH, avec les mêmes problèmes : Quasiment aucun service en ligne n’utilise les certificats clients pour authentifier. Même pour ceux qui le font, cela t’enchaîne à utiliser ta machine. Je souhaite quelque chose qui puisse m’accompagner en trajet.
Éric, plus de sécurité équivaut souvent à plus de contraintes.
La possibilité d’utiliser un bypass rend caduque tout blindage additionnel.
L’utilisation de claviers virtuels, comme sur les sites de banques, complique les tâches d’interception locale.
Les mécanismes de verrouillages et les bonnes pratiques de stockage de mdp sont également à regarder sérieusement.
Enfin, l’utilisation d’otp, distribués sur un canal tiers (security token , téléphone,) permet, à des degrés divers, de renforcer la difficulté d’intrusion.
Pour les utilisations les plus sensibles, l’utilisation d’alarmes silencieuses, déclenchées par des mécanismes de détection internes, voire sur code utilisateur (utilisateur sous contrainte) peuvent être implémentés.
Faut toutefois s’en tenir au juste besoin.
Je trouve l’authentification par certificat très sécurisé, puisque proche du principe SSH.
Le problème reste le support de ce type d’authentification dans les applications. C’est très complexe à mettre en œuvre et n’incite pas les développeurs à autoriser plusieurs identités par compte, ce qui serait une solution au problème de mobilité.
Actuellement, l’authentification par certificat se fait sur SSL, ce qui oblige à la configurer sur le serveur SSL et pas dans l’application. Il faudrait envisager un système similaire basé sur le principe de clé publique/privée mais basé sur HTTP. Ce qui permettrait de le déployer plus facilement directement dans les applications.
Avec un support côté navigateur, il y a moyen de faire quelque chose d’utilisable tout en étant sécurisé. Mais ce n’est pas pour demain…
Le bypass c’est moi qui choisit ou pas de l’utiliser. À moi de faire en sorte de gérer ce risque (ne l’utiliser que là où je suis sûr, exceptionnellement, peut être le changer ensuite, etc.).
Il ne remet pas en cause le principe puisque j’ai beau avoir utilisé un bypass il y a un mois chez moi parce que mon téléphone était en rade, ça n’offre pas plus de possibilités d’attaque au malveillant qui regarde ce que je tape du boulot avec une authentification forte.
Bien sûr cela demande de savoir ce qu’on fait, de mesurer les risques, et d’assumer que le risque n’est jamais nul donc qu’en utilisant le bypass je fais peut être une bêtise mais ça ne rend pas caduque tout le reste pour autant.
Pour le clavier virtuels c’est franchement pour rire et pour dire qu’ils ont fait quelque chose. Il faudra 2h à un bidouilleur pour ajouter une capture d’écran lors du clic. C’est fait depuis longtemps dans beaucoup de spyware (et pourtant que je sache ce système est très français)
Pour moi le stockage de mot de passe est une fausse solution. Déjà ça entraine à stocker le mot de passe quelque part. Ensuite ça implique de le réafficher avant de l’utiliser, donc d’ajouter une potentielle divulgation supplémentaire qui n’existait pas avant. Et ensuite ça ne résoud quasiment pas le problème de la divulgation « sans le savoir » de son mot de passe.
Pour les alarmes j’aime bien ce qu’en fait Google : m’avertir quand il pense qu’il y a eu un accès depuis un autre poste à risque. Ca fonctionne assez bien mais ça reste perfectible. Si on utilise un système par jeton généré, c’est quelque chose d’assez simple à ajouter justement avec un bête compteur. Celui qui copie le générateur de jeton se fait très rapidement repérer simplement parce que d’un coup le compteur fait des sauts ou des retours en arrière.
Pour les besoins et bien … justement, c’est ce que j’ai listé dans le billet. Clairement les systèmes basés uniquement sur mot de passe ne me semblent pas correspondre à ce que je cherche. Pour l’instant j’ai le 2steps de Google et je lies autant que possible dessus via openid. Reste que je trouve encore des défauts qui me gênent (surtout l’absence de contrôle de la solution)
Pour les claviers virtuels je suis d’accord, mais ça complique quand même, notamment quand ce n’est pas ta machine.
Si tu as un code bypass, je peux l’utiliser également et invalider la couche supplémentaire.
Je me suis mal exprimé pour le stockage de mdp: je voulais désigner le stockage de hash sur ton serveur, pas en local ou via un service tiers (tel que lastpass dont une faille a été récemment corrigée).
Bonjour,
Je vous invite à découvrir la solution d’authentification forte sur mobile développée par la société Tagattitude (Startup basée en région parisienne) en vous rendant sur http://www.audiotag.fr/vsa/Tag…
Plus d’infos sur http://tagattitude.fr/en/produ…
Hervé Manceron, Tagattitude.
Le code de bypass tu peux l’utiliser si tu le connais, donc si je l’ai utilisé dans une situation à risque et que tu étais là pour l’intercepter. il est prévu pour usage exceptionnel, et dans l’idéal pas du tout, mais il est important pour gérer le « au cas où », pour que le téléphone (ou autre objet physique) ne devienne pas le problème à l’avenir.
Si tu parlais de faire attention à ce que chaque service stocke des hachages et non les passes en clair, qu’ils demandent une vérification par email lors d’une authentification réussie précédée par de multiples authentifications ratées, nous sommes d’accord que ce serait un gros pas, mais ça ne couvrira là aussi qu’une partie du problème, ça restera une authentification faible. Dans ta liste j’ajouterai aussi le fait d’avoir une graine aléatoire lors du hachage par exemple.
Bonjour, merci pour le lien.
Malheureusement un système qui demande de l’audio c’est un no-go pour moi dans 90% de mes situations : sur le canapé devant la tv, en réunion, au boulot, en conférence, sur un poste de cybercafé, sur mon mobile, etc.
Il est extrêmement rare que le son soit activé sur mon poste, ou que je considère comme socialement acceptable de l’activer.
Bon, désolé d’insister, mais:
Tu as un mdp ‘classique’ de longueur n.
Tu rajoutes une couche de sécurité grâce à l’authent forte et des one time passwords.
Mais tu peux bypasser la ligne précédente grâce à un mdp supplémentaire (dans le meilleur des cas) de longueur n.
Accéder à ton appli revient donc pour un intrus à trouver un mdp de longueur m+n.
Ce n’est plus de l’authent forte, c’est de l’authent classique avec un mdp +long.
non non, insistes, je peux très bien me tromper.
Mais en fait c’est surtout je pense qu’on n’a pas les mêmes risques en tête. Balayer le mot de passe au hasard, que ce soit par combinaison ou par dictionnaire, c’est un risque que j’accepte. Normalement mes mots de passe sont assez bien choisis pour que ça ne soit pas un problème. Si l’appli est bien faite et refuse les tentatives avec X échecs ou si elle les temporise, alors je considère que c’est un risque quasi nul.
Mon risque c’est que le mot de passe soit intercepté, par le réseau (admin du proxy, wifi public, phishing, etc.) ou par un spyware quelconque.
Du coup le mot de passe de secours ne pose problème que si je l’utilise et que dans les situations où je l’utilise. Ca reste de l’authentification faible, nous sommes d’accord, mais j’accepte ce risque dans les situations où je ne peux faire autrement. Ce qui m’intéresse c’est de pouvoir faire autrement l’essentiel du temps.
« Quasiment aucun service en ligne n’utilise les certificats clients pour authentifier. »
C’est vrai, le pendant est que tous ces services qui n’utilisent pas ces certificats stockent mes données en clair chez eux (ou alors ils les stockent en crypté mais gèrent à 100% le cycle de vie des clefs). Donc oui, pour la sécurisation, ça restreint à son service. En même temps, mon serveur est quasiment tout le temps accessible :-)
Bon ben j’allais répondre strictement la même chose, merci Vincent de me faire économiser du Byte.