☞ Deux types de risques de sécurité
En matière de sécurité et de contrôle d'accès, notamment informatique mais pas uniquement informatique, il y a deux risques majeurs qu'il faut prendre en compte :
- le risque qu'une personne non autorisée obtienne l'accès qu'on cherche à contrôler (alors qu'elle ne devrait pas),
- le risque qu'une personne autorisée perde l'accès en question (alors qu'elle devrait l'avoir).
(On pourrait
appeler ça risque de type I
et risque de type II
, mais
personne ne saurait lequel est lequel donc ce n'est pas une bonne
idée, donc il vaut sans doute mieux utiliser des termes
comme intrusion
ou autorisation à tort
dans le premier
cas, exclusion
ou rejet à tort
dans le second cas.)
Pour prendre un exemple en-dehors de l'informatique, si le contrôle d'accès est la porte d'entrée de chez vous, le premier risque est celui qu'on entre chez vous par effraction (ou en crochetant la serrure ou quelque chose de ce genre), le second est celui que vous vous retrouviez à la porte parce que vous avez perdu votre clé. En informatique, dans le cas le plus simple (authentification par mot de passe), le premier risque est celui que votre mot de passe soit cassé ou volé et qu'un intrus accède à votre compte (mail, par exemple), le second risque est celui que vous oubliiez votre mot de passe et que vous ne puissiez plus accéder à votre compte. Rien de bien compliqué, donc.
Un des problèmes majeurs de presque tout mécanisme de sécurité informatique est que ces deux risques sont en tension : les mesures qu'on va prendre pour éviter le premier vont avoir tendance à rendre le second d'autant plus facile, et vice versa. Une attitude rationnelle face au risque est de prendre les deux en compte, c'est-à-dire d'estimer leur probabilité et leur coût, et de chercher des mécanismes tendant minimiser le coût total (somme des probabilité×coût, plus évidemment d'autres éléments de coût). Il y a des conditions[#] où le premier est bien plus prégnant que le second, et d'autres où c'est le second qui est le plus marquant, et d'autres où ils sont tous les deux sont à prendre également au sérieux.
[#] Désolé pour l'ouverture de porte ouverte à la hache, mais je ne voulais pas prendre le risque que quelqu'un se retrouve bloqué par cette porte.
J'ai cependant l'impression que beaucoup de gens, pourtant plutôt bien informés par ailleurs, ont tendance à surestimer le premier risque au détriment du second. Alors oui, c'est vrai que le grand public a tendance à choisir des mots de passe vraiment merdiques, et surtout, ce qui est le pire, à réutiliser le même partout[#2], ce qui pose gravement le risque de l'accès non autorisé, mais il ne faut pas oublier le second risque pour autant.
[#2] Comme je le disais
dans un billet passé, le choix et
la gestion des mots de passe est un vrai problème pour un grand public
qui n'a aucune formation à ça et qui est bombardé de conseils assez
contradictoires. Et même pour quelqu'un qui a des connaissances
raisonnables en sécurité informatique, ce n'est pas du tout évident de
faire des choix intelligents. Utiliser un gestionnaire de mots de
passe est certainement une bonne idée s'il est bien fait (mais il faut
que l'ergonomie soit agréable, il faut que le format de stockage soit
ouvert et documenté, il faut au moins qu'il permette de verrouiller ou
déverrouiller plusieurs niveaux de sécurité de mots de passe, il faut
aussi qu'il ne dépende d'aucun serveur tiers qui risquerait de tomber
en panne, et il faut aussi que vous puissiez facilement ajouter ou
changer les mots de passe sur tous vos ordinateurs et téléphones
depuis n'importe lequel d'entre eux, y compris quand certains sont
éteints, ce qui pose des problèmes pas forcément évidents de
synchronisation). J'utilise moi-même des solutions bricolées dont je
ne suis pas très content (pour les mots de passe les plus basiques
comme ceux de 1 000 000 sites marchands, ils sont simplement stockés
en clair dans un fichier texte sur mon ordinateur en plus d'être
stockés dans le navigateur, et pour ceux qui sont plus critiques, ils
sont dans des fichiers chiffrés auxquels il est plus ou moins pénible
d'accéder). Mais à défaut de solution plus sophistiquée, ma
recommandation générale simple pour le grand public est d'utiliser des
mots de passe formés de la concaténation deux parties : une facilement
mémorisable qu'on choisit toujours la même (prenez un mot assez long
dans le dictionnaire en l'ouvrant au hasard et mémorisez-le), et une
tirée au hasard, avec plein de caractères spéciaux, qui dépend du
site, et qu'on pourra écrire sur un papier en face du nom du site
(donc par exemple, sur www.example.com mon mot de passe
pourrait être implant^97w:C, je
note
sur un
papier, et je retiens example.com → ^97w:C
qui est le même
partout), et on pourra au besoin photographier le papier en question ;
tout ça n'est pas idéal, mais c'est un compromis raisonnable.implant
Or en fait, j'ai entendu beaucoup plus d'histoires d'horreur de gens qui s'étaient retrouvés exclus de l'accès à leur compte informatique (de n'importe quel type que ce soit : adresse mail, réseaux sociaux, domaines Web…) que de gens qui avaient subi une intrusion dessus. Certes, c'est un échantillon minuscule et pas représentatif du tout, et en outre, même si la probabilité du premier risque est plus faible que celle du second ça ne dit rien sur les coûts associés, mais voilà, disons au moins que ce second risque existe, qu'il est bien réel, et qu'il ne faut pas oublier de le prendre en considération quand on décide quelles mesures de sécurité on va utiliser (si on a le choix !).
☞ Mécanismes de contrôle d'accès
Comment contrôle-t-on l'accès à une ressource informatique ? Il y a plein de mécanismes de base possibles. On peut demander que l'utilisateur accrédité connaisse un mot de passe et fournisse ce mot de passe pour se connecter. On peut demander qu'il dispose d'un objet physique, par exemple une carte à puce ou un ordinateur physique ou quelque chose de ce genre. On peut demander qu'il ait déjà accès à une autre ressource, par exemple un numéro de téléphone mobile ou un compte mail ou une adresse postale (cette dernière solution étant, évidemment, très lente à vérifier). Ou dans certains cas on peut vérifier un document d'identité officiel (mais là aussi, ça pose plein de problèmes pratiques). On peut imaginer de faire de la biométrie (reconnaissance d'empreinte digitale, de rétine ou de je ne sais quel autre truc de ce genre), mais en fait, en gros, ça ne marche pas dans le monde réel (il y a tellement de faux positifs et de faux négatifs que ça peut, tout au plus, être utilisé comme raccourci pour remplacer un autre mécanisme moins commode).
Ces éléments peuvent se combiner. Par exemple, on peut demander de se connecter en fournissant un mot de passe et en recevant un SMS sur mobile (ce qui renforce la sécurité) ; ou au contraire on peut demander de se connecter en fournissant un mot de passe ou en recevant un SMS sur mobile (ce qui diminue les risques de perte d'accès). Plus généralement, on peut concevoir toutes sortes de combinaisons entre les éléments de base, formant ce qu'on appelle mathématiquement une fonction booléenne monotone (bon, la procédure est plus compliquée que juste une fonction booléenne entre les mécanismes de base, parce qu'il a un ordre et des informations partielles, etc., mais conceptuellement c'est plus ou moins ça : à partir de quelles combinaisons des éléments de base peut-on obtenir l'accès à la ressource contrôlée).
Ces éléments se retrouvent en-dehors de la sécurité informatique, dans la vie réelle. Certaines personnes, par exemple, ont deux clés pour rentrer chez eux : il faut disposer de la clé principale et de la clé du verrou. C'est censé améliorer la sécurité. D'autres, au contraire, ont peur de perdre leur clé et en mettent un double chez le voisin : auquel cas l'authentification se fera soit par la clé soit par la connaissance sociale du voisin. Ou alors ils cachent un double dans leur jardon : ce qui sera nécessaire pour entrer, alors, c'est de disposer de la clé ou de l'information d'où le double est caché. Tout ça est parfaitement raisonnable en fonction des circonstances.
La solution consistant à demander un mot de
passe ou l'accès à une certaine adresse mail est de plus
en plus répandue pour les comptes de peu d'importance, par exemple
toutes sortes de sites Web marchands (surtout ceux qui ne stockent pas
de numéro de carte
bancaire[#3]). Pour se
connecter à son compte, il faudra alors soit connaître le mot de
passe, sont dire qu'on l'a oublié, auquel cas on recevra un nouveau
mot de passe par mail, ce qui permet donc de se connecter avec l'un ou
l'autre de ces mécanismes (connaissance du mot de
passe ou possibilité de lire le mail reçu à l'adresse
préenregistrée). En fait, de plus en plus, je pense que les gens ne
se fatiguent même pas avec le mot de passe : beaucoup se connectent
systématiquement avec l'option mot de passe oublié
et reçoivent
un nouveau mot de passe à chaque fois. Donc en fait ça revient à dire
que le contrôle d'accès se fait par la possibilité d'accéder à une
certaine adresse mail. Une autre partie des gens laissent simplement
leur navigateur mémoriser leurs mots de passe : le contrôle d'accès
est donc, alors, fait sur la condition d'avoir accès à l'ordinateur et
éventuellement à un mot de passe maître sur celui-ci. Pour des
comptes dont la sécurité n'est pas vraiment critique, tout ça est
c'est parfaitement raisonnable.
[#3] Et honnêtement, s'il y a une chose que je dois recommander pour la sécurité en ligne, c'est de ne jamais stocker de numéro de carte bancaire sur un site Web marchand. Si possible, utilisez des numéros à usage unique (de façon scandaleuse, beaucoup de banques ne proposent pas ça, ou le font payer, alors que c'est quand même largement en leur intérêt que les clients en profitent ; mais je signale à toutes fins utiles que, en France, Fortuneo propose gratuitement ce service), et au strict minimum demandez aux sites marchands de ne pas retenir votre numéro.
☞ Double authentification
Bon, mais pour les comptes de plus grande importance, comment fait-on ? Pour l'accès au compte mail lui-même on ne peut pas vraiment proposer d'envoyer le mot de passe par mail (ou alors il faut que ce soit sur une adresse différente, et il va bien falloir que l'utilisateur consente à retenir un mot de passe ou un autre, ou au moins à le faire retenir par son navigateur). Comme la grande majorité des utilisateurs sont très mauvais pour choisir des mots de passe, il faut quand même trouver un mécanisme pour renforcer un peu la sécurité contre les attaques d'intrusion.
C'est là qu'intervient la double
authentification : il s'agit juste de demander un et
logique entre deux mécanismes de base. Par exemple, demander d'entrer
un mot de passe et de recevoir un SMS ; ou d'entrer
un mot de passe et de recevoir un mail ; ou encore d'entrer un mot
de passe et de disposer d'un téléphone ou ordinateur qui a
préalablement été autorisé. Il y a encore d'autres solutions, mais en
tout cas c'est la conjonction de plusieurs mécanismes.
Pour un site comme celui d'une banque, je trouve que ceci est tout à fait raisonnable : d'une part, l'enjeu est très grand (si quelqu'un obtient un accès à mes comptes bancaires il peut me voler énormément en très peu de temps, donc le coût pour moi est énorme, et la motivation pour lui l'est aussi) ; mais aussi, d'autre part, le second type de risque (celui de l'exclusion) est facile à pallier : si je perds l'accès à mes comptes bancaires en ligne, je vais certainement pouvoir avoir recours à une procédure de récupération, par exemple peut-être que j'irai en agence bancaire avec une pièce d'identité, ou peut-être que je pourrai demander à recevoir de nouveaux codes par courrier recommandé ou que chose comme ça — c'est assez pénible, mais il n'y a pas de risque sérieux de perdre totalement l'accès à tout mon argent parce que je n'ai plus les codes (enfin, sauf peut-être si votre compte est dans les coffres d'une banque suisse[#4], je ne sais pas comment ça se passe si vous perdez la clé/combinaison).
[#4] Pour les coffres d'une banque française accessible au commun des mortels, apparemment il y a moyen de récupérer le contenu si on perd la clé : une amie m'a dit avoir hérité du contenu d'un tel coffre et ne trouvait pas la clé, il a été possible, moyennant des démarches compliquées et sans doute beaucoup de frais, de faire intervenir un serrurier spécialisé habilité à intervenir pour ouvrir le coffre.
Bref, pour un site bancaire ou un site de paiement je trouve ça tout à fait normal et souhaitable qu'on vous demande à la fois de mémoriser des codes d'accès (et là, pour le coup, ne les stockez pas dans votre navigateur sauf si vous avez mis un mot de passe maître vraiment sérieux dessus) et de recevoir un code par SMS ou quelque chose de ce genre[#5]. Autrement dit, sur un site bancaire, je trouve normal que non seulement on mette en place une double authentification, mais même qu'on l'impose au client[#6]. Il faut d'ailleurs se demander si la double authentification en est vraiment une, parce que si les gens utilisent leur téléphone mobile pour accéder à leur compte bancaire, il y a des chances que les deux éléments de l'authentification (le mot de passe, qui serait stocké sur le téléphone, et la double authentification, qui serait un SMS reçu sur le téléphone ou passerait par une application sur celui-ci) viendraient quand même du même objet, et ce n'est pas très clair comment on peut éviter ce souci.
[#5] Bon, le quelque
chose de ce genre
est peut-être un peu rapide ici. Ça peut
signifier passer par une application mobile spécifique, et là,
contrairement au SMS, c'est véritablement problématique.
Il y a une directive européenne appelée DSP2 (Directive
sur les Services de Paiement) qui est assez désastreuse et mal pensée
à cet égard, parce que, pour ce qui est des smartphones, il semble
qu'elle interdise la double authentification par SMS (je
ne sais pas par quelle astuce légale Fortuneo réussit quand même à
s'en servir, mais ça fait partie des raisons pour lesquelles je suis
content d'être chez eux), et en plus cette directive va exiger toutes
sortes de contraintes sur l'application mobile, qui, pour être
vérifiées, vont exiger de contrôler la totalité de ce qui se passe
sur le mobile (par le mécanisme totalitaire que Google appelle
le Play
Integrity), c'est-à-dire, notamment, que ça exclut probablement
tous les Android communautaires (tels que Lineage OS,
celui que j'utilise). Donc juste parce qu'un imbécile a décidé que
les SMS n'étaient pas assez sûrs, on se retrouve à
imposer tout ce qui doit tourner sur votre téléphone (ce qui revient à
vous déposséder de vos droits dessus) et on fait ainsi un pas de plus
vers la dystopie que je
décri(v)ais ici
et là. (Bon, en principe la banque
doit pouvoir fournir autre chose qu'une application sur smartphone,
mais quoi exactement… ce n'est pas clair. Surtout si on veut quelque
chose qui va tourner dans un environnement de logiciels libres.) Pour
plus d'explications, voir le fil Twitter qui
part ici
(vous pouvez peut-être le
lire ici
si vous n'avez pas de compte Twitter) ainsi que les différentes
branches qu'il référence.
[#6] Entre autres questions liées, il y a celle de savoir si des tentatives d'accès incorrectes répétées doivent verrouiller le compte client (le déverrouillage étant, bien sûr, possible, mais compliqué, et nécessitant peut-être un passage en agence bancaire). Une carte bancaire, par exemple, s'auto-verrouille (voire, s'auto-détruit) si on tente de façon répétée d'utiliser un code PIN incorrect. C'est un compromis qui permet de se contenter d'un code PIN de seulement quatre chiffres, ce qui semble être la limite de la capacité de mémorisation du grand public, tout en gardant une sécurité convenable (parce que sinon, tester un par un les 10000 codes possibles serait juste long et fastidieux mais absolument pas impossible). Mais pour un site Web c'est peut-être plus compliqué, parce que ça veut dire qu'avec la simple connaissance de l'identifiant d'un client on pourrait verrouiller accès de ce dernier en multipliant les essais infructueux de connexion.
☞ Entre le site marchand et le site bancaire
Bon, donc pour un site marchand quelconque non seulement on ne veut pas de double authentification mais on veut pouvoir récupérer le mot de passe par simple envoi d'un mail, et pour un site bancaire on veut une double authentification et c'est raisonnable qu'elle soit imposée. Mais entre les deux ? C'est là que ça se complique.
Google, par exemple, met une pression très forte pour que les gens
activent la double authentification sur leur compte Google/GMail. Et
dans certains cas c'est raisonnable (si c'est votre mail principal, ce
qui est le cas de beaucoup de gens). La double authentification
Google est compliquée, et je ne comprends honnêtement pas tous les
mécanismes qu'elle
implique[#7]. Mais pour
quelqu'un comme moi qui n'a rien d'important sur son compte Google ou
dans sa boîte GMail (et qui voudrait continuer à ne rien avoir
d'important dessus, merci d'arrêter de me pousser à lier plein de
choses à ce compte), la double authentification est juste pénible
et sans intérêt, enfin, sans intérêt pour moi, parce que Google y
trouve sans doute un avantage. Pour l'instant ce n'est pas
obligatoire mais ils poussent de plus en plus dans ce sens (et, comme
le dit la note #7 suivante, je
ne comprends même pas le labyrinthe des modes d'authentification
« simple »). Et cette pression deviendra d'autant plus forte que
beaucoup de sites se défaussent du problème d'authentification en le
repoussant chez Google (connectez-vous via votre compte
Google
[#8]).
[#7] Je crois que l'idée est la suivante : votre accès primaire se fait par la combinaison d'un mot de passe et de l'accès à (un autre mail ou un téléphone) préalablement enregistrés sur le compte. Mais une fois que vous avez fait une double authentification avec succès, une clé temporaire est stockée dans votre navigateur ou dans le téléphone qui a fait l'accès avec succès : cette clé temporaire fait qu'on ne vous demandera plus de double authentification depuis cet appareil (jamais ? pendant un certain temps ? je n'en sais rien), voire, plus d'authentification du tout, et, en plus, cet appareil vous permettra de servir à son tour de jeton de double authentification d'un autre appareil (c'est-à-dire qu'au lieu de recevoir un mail tiers ou un SMS, vous allez pouvoir authentifier un nouveau navigateur en l'approuvant depuis un téléphone déjà connecté à votre compte Google). Enfin, quelque chose comme ça. L'idée générale ne semble pas idiote, mais ce qui est surtout agaçant, c'est que comme tout ce qui concerne Google, on ne comprend rien aux détails, ils ne sont expliqués nulle part (et ils changent certainement tous les trois mois) ; il y a plein de façons d'être connecté, ou à moitié connecté, ou pas vraiment connecté, à plein de sous-services Google, et on ne sait pas quels sont les paramètres qui jouent vraiment, donc au final c'est un labyrinthe. Il y a sans doute un automate fini sous-jacent qui décrit tous les états possibles de connexion d'un compte Google sur un appareil et ce que chacun permet de faire, mais je n'ai aucune idée du nombre d'états qu'il a.
[#8] Le connectez-vous via votre compte
Google
est un piège. Ostensiblement, il rend service à
l'utilisateur en lui épargnant d'avoir à mémoriser un mot de passe.
Mais en vrai, ça relie un de vos comptes, qui devraient rester
indépendants, à la galaxie Google. Non seulement ça veut dire que
Google va savoir encore un peu plus de tout ce que vous faites en
ligne, mais, symétriquement, ça veut dire que l'autre compte va savoir
quelle est votre identité Google (et peut-être votre vrai nom), et va
pouvoir vous empêcher de créer des comptes multiples. Et en plus de
ça, ça veut dire que si un jour Google décide qu'il ne vous aime pas
(par exemple parce que vous auriez posté un commentaire sur une vidéo
YouTube avec un mot interdit et qu'ils vous auraient aléatoirement
sanctionné par la fermeture de votre compte), vous allez perdre
l'accès à tout ce qui a été lié à ce compte Google. Donc ne faites
jamais ce genre de choses : si on vous propose de vous connecter avec
un compte Google, refusez et utilisez simplement un mot de passe.
Et sur les réseaux sociaux, pareil : à moins que vous soyez un influenceur ultra-célèbre, votre compte Facebook ou Twitter ou que sais-je n'a aucune importance, vous n'avez pas besoin de double authentification, elle ne servira qu'à vous emmerder[#9]. Utilisez simplement un mot de passe unique et sérieux.
[#9] Enfin, concrètement, elle servira au propriétaire du site à récupérer votre mail et/ou votre téléphone, et à vous profiler ou bien à le vendre à des spammeurs.
☞ Le risque de se retrouver coincé à la porte
Le vrai problème avec la double authentification c'est que ça multiplie les chances de se retrouver complètement exclu du compte (ce qui, pour la grande majorité des gens, est un risque à la fois plus probable et finalement plus grave que l'intrusion). S'il faut deux éléments pour se connecter, ça fait en gros deux fois plus de chances d'en perdre[#10] un.
[#10] Ici, perdre
peut prendre
différentes formes. Ça peut être une résiliation (d'un abonnement
téléphonique ou d'un compte mail) dont on n'a pas mesuré les
conséquences. Par exemple, quand mon père est décédé, j'avais
le mot de passe de son compte Google, mais son abonnement
mobile avait été résilié sans réfléchir à ce que ça impliquait. À
cause de la double authentification ce n'était pas évident de trouver
moyen de m'y connecter : heureusement, son téléphone fonctionnait
encore sur wifi et pouvait se connecter au compte Google, et quelque
part dans la machine à états incompréhensible des connexions Google,
il était possible de passer de connaissance du mot de passe + accès
à un téléphone connecté au compte sur wifi
à un état plus pérenne.
Mais j'ai entendu des histoires de gens qui n'ont jamais pu obtenir
l'accès aux comptes mails ou sur les réseaux sociaux de proches
disparus, souvent à cause de cette fichue double authentification.
Et contrairement à votre banque, Google ou équivalent ne remuera probablement pas le petit doigt pour vous aider à retrouver un accès à votre compte parce qu'il vous manque un des deux éléments nécessaires à la connexion.
Disons que voici une condition sous laquelle la double authentification (même imposée) sera raisonnable à mes yeux : s'il y a un moyen prévu pour que, à partir d'une pièce d'identité officielle et d'une déclaration préalable d'identité associée au compte, on puisse recréer un accès même en ayant perdu tous les éléments d'authentification. (Quitte, évidemment, à payer : il s'agit d'une procédure exceptionnelle, je comprends que ça ne soit pas gratuit. La compagnie peut très bien faire payer quelque chose comme 50€ pour le temps de travail nécessaire à un humain à contrôler sérieusement une identité légale et proposer un moyen de débloquer le compte.) Mais je pense que, en pratique, quasiment personne ne propose quoi que ce soit de ce genre : en tout cas certainement pas Google, Facebook, Twitter⌫𝕏 ou je ne sais quel site de ce genre.
☞ Les catch-22
Voici encore un cas de figure, qui concerne moins le grand public, mais qui est quand même important : les comptes liés à des services informatiques. Par exemple un fournisseur d'accès Internet, un hébergeur de serveurs ou de sites Web, ou encore la location de domaines Web.
Pour ce genre de services, la double authentification peut devenir un cauchemar parce qu'elle peut conduire à des boucles vicieuses (des catch-22) : si on cherche à se connecter aux services d'un hébergeur informatique, c'est probablement qu'on a un problème informatique, et ces problèmes sont peut-être justement de nature à empêcher le bon fonctionnement de la double authentification.
Les catch-22 ne concerne pas que les services pour geeks, d'ailleurs : j'ai récemment entendu quelqu'un raconter qu'il avait cassé son téléphone, et qu'il essayait d'en racheter un, mais que pour payer en ligne son nouveau téléphone, il lui fallait passer par le site de sa banque, qui exigeait une double authentification… par un SMS envoyé au téléphone cassé. Bon, là c'est assez facile de contourner le problème (demander une nouvelle carte SIM à son opérateur, ou demander à la banque de changer l'accès aux comptes en ligne). Mais sur les hébergements de services informatiques ça peut être quelque part entre très chiant et carrément impossible.
Par exemple, mon poussinet administre une machine qui sert à la fois à divers anciens élèves de l'ENS mais aussi à stocker les mails personnels du poussinet. Cette machine est hébergée par OVH. Récemment elle a eu un souci qui nécessitait un redémarrage de force par l'hébergeur. C'est alors qu'on s'est rendu compte que l'identification auprès de l'hébergeur pour demander ce redémarrage passait par une double authentification avec l'envoi d'un mail. Lequel était envoyé à l'adresse du poussinet. Qui est justement hébergée sur la machine qui ne marchait plus. Catch-22 ! (En principe, on aurait dû pouvoir utiliser un mail de secours, qui, lui, était chez GMail, donc ça aurait dû marcher. Mais l'interface de l'hébergeur semblait avoir changé et nous ne trouvions absolument pas comment demander d'envoyer le jeton de double authentification sur l'adresse de secours.)
Il y avait moyen de s'en sortir, certes. Le compte est associé à une personne physique[#11], donc il y aurait certainement eu moyen (enfin, j'espère) de demander une réinitialisation des mécanismes d'authentification par courrier papier, ou quelque chose comme ça (mais ça aurait pris plusieurs jours, et sur une machine qui héberge plein de mails et de service, c'est tout de même très pénible). Il y avait sans doute aussi moyen de s'en sortir autrement, mais péniblement[#12], et nous avons été très soulagés de voir que la machine a redémarré toute seule (enfin, après intervention de l'hébergeur, mais sans requête de notre part).
[#11] À un certain
moment, beaucoup de choses relatives à cette machine étaient déclarées
au nom de l'Armoire de la salle S, École normale supérieure, 45 rue
d'Ulm, 75 230 Paris cedex 5
(et cette armoire a, il me semble,
effectivement reçu du courrier adressé ainsi), mais je crois que ce
n'est plus le cas (ce qui vaut mieux vu que ni la salle ni l'armoire
n'existent plus).
[#12] En l'occurrence,
pour ceux qui savent ce que ça veut dire, en changeant
le MX enregistré dans le DNS de manière à
envoyer le mail sur une machine que je contrôle. Mais ça aurait pris
plein de temps et le potentiel de merdes (et de mails perdus) était
énorme.
Alors oui, bien sûr, on peut dire que c'est la faute du poussinet d'avoir associé le compte qui hébergeait la machine à une adresse mail sur la machine elle-même (et cette erreur a été corrigée). Mais même comme ça, ça reste très insatisfaisant : s'il faut utiliser un mail tiers, ça oblige à s'assurer qu'il fonctionne fiablement, ce qui n'est pas si évident si ce n'est pas un mail qu'on contrôle pleinement. Et il peut y avoir des cycles plus compliqués (si deux services tombent en panne et que chacun nécessite un accès à l'autre pour réparer la panne : catch-22). Et puis il peut y avoir d'autres sortes de soucis.
Ce qui déclenche l'écriture de ce billet, c'est un problème que
j'ai eu ce matin avec mes domaines Web
(madore.org, gro-tsen.net
et ⁂.net) enregistrés
chez DomainDiscount24.
Ceux-ci ont décidé récemment (bande de cons !) de rendre obligatoire
la double authentification sur tous les comptes qu'ils hébergent.
Avec, par défaut, double authentification par envoi de mail. J'avais
eu la bonne idée, moi, de ne pas associer le compte associé au
domaine madore.org à une adresse mail sur le
domaine madore.org : j'avais choisi une adresse à vie à
l'ENS. Encore faut-il qu'elle fonctionne : quand
j'essaie de me connecter ce matin, le site m'affirme qu'il m'envoie un
jeton d'authentification par mail, mais je ne vois rien arriver dans
ma boîte mail (dont je sais pourtant qu'elle fonctionne en général).
Nouveaux essais infructueux. Je commence à paniquer : si je n'arrive
pas à me connecter, je perds tous mes domaines et je n'aurai sans
doute aucun moyen de les récupérer. Heureusement ce n'était qu'un
problème mineur dont je me suis souvenu : le serveur mail en question
a une forme
de greylisting
(c'est une mesure de lutte contre le spam) qui retarde de 15 minutes
la réception des mails depuis des émetteurs inconnus, et le serveur
mail de DomainDiscount24 était inconnu. Donc un quart d'heure après,
les jetons me sont quand même
arrivés[#13]. Et j'ai pu
mettre en place un mécanisme différent de double authentification,
basé sur des mots de passe à usage unique (oathtool sous
Linux), qui me semble avoir moins de chances de casser : c'est juste
plus pénible pour moi.
[#13] Avec le souci supplémentaire que chacun invalidait les précédents (donc j'ai dû attendre que le dernier arrive pour pouvoir me connecter, parce que tous les autres avaient été invalidés par l'émission du suivant). Ceci est juste complètement stupide : un jeton d'authentification de ce genre doit être invalidé par le passage du temps ou par une demande expresse de l'utilisateur, pas par l'émission d'un autre jeton (qui peut avoir été requise justement parce qu'on ne sait pas si le précédent arrivera bien).
Mais si le problème avait été plus sérieux (par exemple un problème de routage mail permanent entre le serveur de DomainDiscount24 et celui de l'ENS), je ne pouvais rien faire et j'étais coincé, justement parce que l'adresse choisie n'était pas vraiment sous mon contrôle. Et je suis assez sceptique sur le fait que DomainDiscount24 aurait accepté de me dépanner (par exemple sur la base d'un échange de courriers papiers à l'adresse enregistrée dans les contacts ; bon, il y a la difficulté supplémentaire que le téléphone associé au compte était périmé, et j'ai pu en profiter pour corriger ça).
La moindre des choses, quand on exige une double
authentification, surtout si on ne va pas mettre en place une
procédure de récupération sur la base de l'identité légale (moyennant
paiement de frais) comme je le suggère un peu plus haut, c'est de
fournir le choix à la connexion entre plusieurs moyens de
double authentification. Donc concrètement, je devrais entrer mon
identifiant et mot de passe, le site me dirait il faut maintenant
envoyer un jeton de double authentification : où voulez-vous
l'envoyer ?
et me proposerait le choix entre plusieurs adresses
et/ou numéros de téléphone que j'aurais pré-enregistrés — donc il
suffit d'avoir accès à l'un d'entre eux, et là ça redevient
raisonnable. Et il n'y a aucune raison de ne pas autoriser de
pré-remplir une demi-douzaine de téléphones ou de
mails[#14] pour cet usage. Là
ça rendrait la double authentification raisonnable (enfin, en laissant
en suspens la question de savoir comment on récupère l'accès si c'est
le mot de passe qui est
perdu[#15]) ; mais
DomainDiscount24 ne fournit pas ça, et quasi personne ne le fait.
[#14] D'ailleurs, il y a aussi une raison pratique à permettre de préenregistrer plusieurs mails auxquels on aurait la possibilité d'envoyer le jeton : c'est que plusieurs personnes différentes peuvent vouloir se connecter au compte. Le compte EDF du domicile que je partage avec le poussinet exige une double authentification pour se connecter (bande de cons !). Mais nous voulons tous les deux pouvoir consulter nos factures : comment est-on censé faire ? Ce que j'ai fait est de créer une adresse mail ad hoc qui est redirigée vers nous deux. Mais ça veut dire qu'à chaque fois que l'un d'eux se connecte, l'autre reçoit un spam d'EDF avec le jeton d'authentification. Alors qu'ils auraient pu permettre de préremplir plusieurs adresses mail et d'envoyer le jeton sur celle qu'on choisit à la connexion. Même problème pour le compte de notre fournisseur d'accès Internet (OVH, là aussi) ; et, comme j'ai aussi un accès au compte du fournisseur d'accès Internet de ma mère (pour aider au dépannage en cas de problème), ça veut dire que là aussi je reçois un spam à chaque fois qu'elle s'y connecte et réciproquement. C'est aberrant. Tous ces gens ne réfléchissent vraiment pas aux procédures qu'ils mettent en place, ou ils n'ont aucune notion de sécurité informatique, c'est quand même assez inquiétant.
[#15] Je pense que quand je serai un peu moins débordé par les choses à faire je vais écrire à DomainDiscount24 pour leur demander de m'expliquer ce qu'ils ont comme procédures en place pour les clients qui perdent soit leur mot de passe, soit leur jeton de double authentification, soit les deux. S'ils ne me répondent pas ou si leur réponse n'est pas satisfaisante, je chercherai à trouver un autre registrar à qui louer ces domaines. Encore faut-il que j'arrive à les contacter pour poser la question, ce qui n'est déjà pas évident (et c'est de mauvais augure pour la réponse).
☞ Il faut proposer des solutions flexibles
Fondamentalement, les bonnes solutions robustes à ces problèmes
d'authentification, c'est de mettre en place des mécanismes flexibles
et configurables au cas par cas. Par exemple ça pourrait être une
solution k parmi n
si c'est ce que
l'utilisateur trouve
opportun[#16] : du
style l'accès au compte requiert deux des quatre choses
suivantes : la connaissance d'un mot de passe, la réception d'un jeton
par mail, la réception d'un jeton par SMS, et la
réception d'un jeton par courrier papier ; ou encore, en ultime
recours, une vérification d'identité légale en personne, qui vous sera
facturée 50€
(et pour les gens qui veulent plus de sécurité, ils
auront l'option de remplacer deux des quatre
par trois des
quatre
ou de changer la liste ou d'ajouter un mot de passe à usage
unique généré par un protocole standardisé). Et plus généralement, on
devrait avoir une certaine flexibilité, je ne dis pas forcément de
mettre en place n'importe quelle fonction booléenne monotone, mais au
moins de choisir entre plusieurs niveaux de sécurité ou compromis
entre les deux risques que j'évoque en tête de ce billet.
[#16] En lien avec ça, signalons à toutes fins utiles qu'il existe des méthodes de partage de secret permettant, par exemple, de prendre un message secret (par exemple un mot de passe) et de le scinder en n parties de manière à ce que disposer de ≥k quelconques parmi elles permettent de reconstituer le message d'origine, tandis que si on en a <k alors on ne peut absolument rien savoir du message d'origine, à part peut-être sa taille. (Et si on admet que les parties soient toutes aussi longues que le message d'origine, alors ceci est vrai non seulement au sens de la cryptographie mais même au sens de la théorie de l'information, c'est-à-dire que si vous n'avez que k−1 parts du secrets, quelles qu'elles soient, même avec des moyens de calcul infinis vous ne pouvez absolument rien en déduire sur le message, tandis qu'avec k d'entre elles, quelles qu'elles soient, vous le reconstituez parfaitement.) L'idée est qu'avec ce genre de mécanisme, on peut par exemple prendre un mot de passe très important, le scinder en, disons, n=8 parts et les donner à des amis différents, de façon à ce que, disons, k=5 quelconques d'entre eux puissent collectivement reconstituer le mot de passe : ça peut être une façon de se ménager un système de récupération de ses données secrètes (ou comme provision en cas de décès) sans faire complètement confiance à aucun ami mais quand même confiance dans le fait qu'ils sont majoritairement honnêtes. J'avais il y a bien longtemps écrit un programme qui fait ça dans la pratique (et ce programme m'avait valu de remporter l'IOCCC sans y participer, ce qui est assez fort). Malheureusement, il manque sans doute à ce programme une interface « conviviale » permettant de le rendre vraiment pratique (ainsi qu'un standard sur la manière de présenter les parts du secret).
En attendant, les mécanismes de double authentification imposés, qui ne proposent ni de préremplir une liste raisonnable d'adresses mails et téléphones (entre lesquels choisir au moment de la connexion), ni de solution d'ultime recours par vérification de l'identité légale, sont une connerie.