![[MàJ] Mots de passe : bilan des mauvaises pratiques des sites et services](https://cdn.next.ink/inpactv7/data-next/images/bd/wide-linked-media/4990.jpg "[MàJ] Mots de passe : bilan des mauvaises pratiques des sites et services")
De trop nombreux services ne respectent toujours pas les règles élémentaires de sécurité sur les mots de passe. On ne parle pas ici des utilisateurs qui doivent en utiliser de suffisamment robustes, mais des sites et services qui les envoient par email, les stockent en clair dans leurs bases de données ou imposent des règles étranges. Voici un petit florilège de ce qu’il ne faut pas faire.
Au début de l’année, nous avions lancé un appel afin que vous nous fassiez part de vos retours d’expérience sur la gestion des mots de passe. Peu de temps avant, nous étions en effet tombés sur Wekiwi qui multipliait les faux pas, et c’était peu de le dire.
- Wekiwi envoie des mots de passe en clair, le service client les renvoie à une adresse email non vérifiée
- Gestion catastrophique des mots de passe par des sites et services : faites-nous part de vos expériences
Hacher et saler : on ne stocke pas directement les mots de passe
Si des mauvaises pratiques sont malheureusement encore trop courantes sur Internet, il est important de rappeler quelques principes généraux avant d’entrer dans les détails. La première, triviale, est que « les mots de passe ne doivent jamais être stockés en clair », martèle la CNIL :
« Lorsque l’authentification a lieu sur un serveur distant, et dans les autres cas si cela est techniquement faisable, le mot de passe doit être transformé au moyen d’une fonction cryptographique non réversible et sûre [scrypt et Argon2 sont cités en exemple, ndlr], intégrant l’utilisation d’un sel ou d’une clé ».
Et, pourtant, au fil des fuites de données, on apprend plus ou moins régulièrement que des mots de passe en clair (ou avec un chiffrement faible) se retrouvent dans la nature. Utiliser une fonction cryptographique non réversible permet de vous protéger : le pirate ne pourra normalement pas retrouver votre mot de passe à partir de son empreinte… si les choses sont bien faites évidemment.
Mot de passe en clair dans un mail, c’est non !
Un premier cas revient souvent dans les mails que nous avons reçus : après inscription, le service envoie le mot de passe en clair à l’utilisateur. Premier point : cela ne signifie pas obligatoirement que le mot de passe est stocké en clair. Le site peut le récupérer directement du formulaire d'inscription, l’envoyer par mail, puis le hacher et saler avant de le sauvegarder dans sa base de données.
Par contre, si l'on utilise la fonction de passe perdu et qu’on le reçoit en clair, c’est une autre histoire. Cela signifie soit qu’il est stocké en clair, soit qu’il est chiffré, mais que la société détient de toute façon la clé. Dans les deux cas, cette pratique est à proscrire, mais elle est encore utilisée par certains en 2023. Hacher et saler ne permet pas de retrouver le mot de passe d’origine, c’est tout l’intérêt.
Quelle que soit la situation, on ne devrait pas recevoir de mot de passe (en clair) par email, que ce soit à l’inscription ou en cas de mot de passe perdu. La CNIL est d’ailleurs très claire sur le sujet dans ses recommandations de 2022 (et c’était déjà le cas en 2018) :
« À l'exception des envois par voie postale, les mots de passe ne doivent pas être communiqués à l'utilisateur en clair, notamment par courrier électronique. Seuls des mots de passe temporaires ou à usage unique devraient être communiqués aux utilisateurs ».
Oui, mais vous comprenez… « c’est plus simple »
Nous avons également reçu des témoignages de développeurs, à qui l’on demande d’implémenter une fonction pour envoyer des mots de passe par emails. « J'ai protesté, en expliquant que l'envoi d'un mot de passe en clair par e-mail était contraire aux règles élémentaires de sécurité, et qu'il fallait plutôt envoyer un lien de réinitialisation du mot de passe. Mais il m'a été rétorqué que les utilisateurs qui contactent le support client ne sont pas assez doués pour ça », nous explique l’un d’entre eux. L’excuse du « c’est plus simple » revient malheureusement souvent.
Pour rappel, l’envoi d’un mot de passe en clair dans un email vous expose à plusieurs risques. Si votre boite est piratée, il suffit à une personne malintentionnée de parcourir vos messages pour retrouver les mots de passe envoyés lors de la phase d’inscription ou de la procédure de mot de passe perdu. Elle peut alors se connecter à votre place.
Longueur et caractères spéciaux : attention aux non-dits
Le deuxième point qui revient souvent concerne la longueur des mots de passe. Un utilisateur nous explique ainsi qu’un service « bloque les mots de passe à 20 caractères, mais sans le dire. Très pratique pour ne pas comprendre après coup pourquoi le mot de passe généré ne marche pas ».
Un autre nous relate que le mot de passe est limité à « 16 caractères max et pas tous les caractères spéciaux, ce qui dans un premier temps surprend lorsqu'on reste bêtement sur la page de renouvellement sans savoir pourquoi et ce parce qu'on a utilisé un { au lieu d'un [ ».
« Au moment de la création de mon mot de passe, je me suis rendu compte que l'on devait choisir entre 8 et 12 caractères, impossible d'en mettre plus, je n'ai donc pas pu utiliser celui que je voulais », nous explique une autre personne.
La CNIL et l’ANSSI sur la longueur des mots phrases de passe
La CNIL explique qu’il « convient de fixer une taille maximale pour les champs des mots de passe », mais prend soin d’apporter des précisions pour éviter de se retrouver avec 12 ou 16 caractères maximum :
« Celle-ci doit être suffisamment grande pour permettre l'utilisation de phrases comme mots de passe, tout en évitant les attaques par déni de service résultant du traitement d’un mot de passe abusivement long. Leur taille maximale ne saurait en principe être inférieure à 50 caractères pour une authentification par mot de passe avec ou sans restriction de compte (cas no 1 et 2). Elle pourra être, par exemple, de l’ordre de quelques centaines de caractères ».
À l’ANSSI, on souffle le chaud et le froid, mais on est finalement assez raccord avec la CNIL. En effet, la recommandation 22 indique clairement : « Ne pas imposer de longueur maximale pour les mots de passe. Selon les systèmes, il est recommandé de ne pas fixer de limite à la longueur maximale d’un mot de passe afin de permettre aux utilisateurs d’avoir recours à des phrases de passe ou longs mots de passe ».
L’Agence précise néanmoins que, en pratique et selon les systèmes utilisés (application Web ou Windows par exemple), « il paraît néanmoins raisonnable de fixer une valeur limite (plusieurs centaines de caractères par exemple) afin de ne pas s’exposer à de potentielles attaques en déni de service (qui consisterait à soumettre des mots de passe de plusieurs Mo au vérifieur et pouvant prendre plusieurs minutes à traiter) ».
- Phrases de passe : l'ANSSI passe en mode 2.0
- Phrases de passe : la CNIL passe elle aussi en mode 2.0
D’autres sites et services ne simplifient pas la vie de ceux utilisant un gestionnaire de mots de passe. Certains « désactivent la possibilité de coller un mot de passe dans le champ pour confirmer son mot de passe. Cela rend de fait très compliqué l'utilisation d'un gestionnaire de mots de passe de type KeePass, abaissant ainsi potentiellement la sécurité de son mot de passe », nous explique un lecteur par email.
Notez que ce n’est pas parce que le copier/coller est désactivé dans un champ texte qu’un gestionnaire de mots de passe ne peut pas y insérer le mot de passe automatiquement. Nous avons déjà rencontré plusieurs fois ce cas de figure sur des sites.
Entropie mon amie
De son côté, la CNIL ne parle plus de longueur minimum de mot de passe, mais d’entropie. Dans ce contexte, il s’agit de « la quantité de hasard. Pour un mot de passe ou une clé cryptographique, cela correspond à son degré d’imprédictibilité théorique, et donc à sa capacité de résistance à une attaque par force brute ». On peut aussi parler de la « force » ou de la « résistance » du mot de passe.
La Commission nationale de l'informatique et des libertés propose un outil pour calculer l’entropie d’un mot de passe. Elle précise aussi qu’il est aussi possible de réaliser un calcul dynamique de l’entropie directement dans un champ HTML, via un code JavaScript.
Elle donne trois exemples équivalents en termes d’entropie :
- « les mots de passe doivent être composés d'au minimum 12 caractères comprenant des majuscules, des minuscules, des chiffres et des caractères spéciaux à choisir dans une liste d'au moins 37 caractères spéciaux possibles ;
- les mots de passe doivent être composés d'au minimum 14 caractères comprenant des majuscules, des minuscules et des chiffres, sans caractère spécial obligatoire ;
- une phrase de passe doit être utilisée et elle doit être composée d’au minimum 7 mots. »
La Commission définit « un niveau minimal générique de 80 bits d'entropie pour un mot de passe sans mesure complémentaire ». Lorsque des mécanismes de restriction d’accès sont ajoutés, l’entropie descend à 50. Cela peut être une temporisation d'accès au compte après plusieurs échecs, un nombre maximal de tentatives autorisées dans un délai donné, un Captcha, le blocage du compte après 10 échecs, etc.
Enfin, on passe à une entropie de 13 seulement si la personne détient du matériel « en propre », comme une carte SIM ou une carte bancaire, avec un blocage au bout de trois tentatives échouées. Une entropie de 13 correspond à un code PIN à quatre chiffres, les cartes bancaires sont donc dans les clous.
Utiliser un identifiant interne à la place d’un email
Une question se pose lorsque l’identifiant n’est pas l’email, mais une chaine alphanumérique générée par le service. Un exemple remonté par un utilisateur d’une compagnie aérienne :
« Après avoir installé BitWarden, je me suis rendu compte que mon compte […] est protégé par un mot de passe à six chiffres, et en fait c'est obligatoire. Oui, vous avez bien lu, on ne peut taper que des chiffres... et que six chiffres. La seule chose rassurante, c'est que l'identifiant n'est pas l'adresse email, mais une chaine de caractères qui commence par [deux lettres] suivies de neuf chiffres ».
Selon le référentiel de la CNIL, l’entropie du mot de passe à six chiffres est loin d’être suffisante, même si des mécanismes de restriction d’accès sont ajoutés. Dissocier l’email permet-il de renforcer la sécurité ? Dans ce cas, quelle serait l’entropie minimum ?
La CNIL nous répond qu’un « identifiant interne n’allège en principe pas, au regard de la nouvelle recommandation, l’exigence de sécurité (donc l’entropie) sur le secret lui-même (qui d’ailleurs n’a pas vocation à être connu par l’employeur ou le service) ».
Néanmoins, « il n’est pas nié que cette modalité peut contribuer à améliorer la sécurité du dispositif, notamment en diminuant le risque d’attaques par réutilisation de couples identifiant/mots de passe récupérés via une autre source par un attaquant éventuel ».
Enfin, la Commission nous précise que « l’identifiant ne saurait être assimilé à un secret partagé dans la mesure où, d’une part, il est stocké en clair dans la base de données et, d’autre part, il est difficilement possible de le modifier en cas de compromission. D’une manière plus générale, lorsque l’authentification repose sur un secret partagé, alors il faut appliquer la recommandation à ce dernier, ce qui inclue notamment les exigence de stockage et de renouvellement ».
L’authentification forte « encouragée », mais pas assez répandue
Enfin, rappelons que la CNIL « encourage la mise en œuvre d’une double authentification, ou authentification forte, lorsque cela est possible ». En vertu de l’article 32 du RGPD, c’est même indispensable dans certains cas, notamment « lorsqu’il y a des risques importants pour les personnes dans le cas d’une usurpation de compte ».
La double authentification permet pourtant de grandement limiter les risques puisque, en cas de fuite de votre mot de passe, il faudra avoir en plus un code unique pour accéder au service (notez que la CNIL recommande de ne plus utiliser le SMS). Si vous recevez un code alors que vous n’êtes pas en train de vous connecter, c’est signe qu’une tentative de piratage est en cours.
Enfin, certains services envoient également un message à chaque nouvelle connexion, vous permettant de recevoir immédiatement une alerte en cas de piratage.
Envoyez-nous vos expériences !
Dans un prochain article, nous reviendrons en détails sur les services qui font encore n’importe quoi avec les emails de leurs utilisateurs… et ils sont malheureusement nombreux. Pour rappel, vous pouvez nous faire part de vos retours à cette adresse :
Commentaires (53)
#1
Attention aux expressions “double authentification” et “authentification forte”, qui ne sont pas synonymes.
Je me propose de citer l’ANSSI à ce sujet :
Sinon, concernant la double authentification, une limitation encore trop présente que je constate, c’est la pauvreté des méthodes disponibles pour beaucoup de services, qui limite les facteurs disponibles à… 2 (dont une est le mot de passe) !
En cas de perte ou d’indisponibilité d’un des facteurs, l’authentification est alors impossible.
Exemple classique : le domaine bancaire. Les banques imposent la double authentification aujourd’hui (obligation européenne). Bien trop souvent, cela se limite à une application sur smartphone. Perte ou casse du smartphone => impossibilité de se connecter à sa banque, ou de valider des paiements par internet.
Et lorsque cela m’est arrivé (casse téléphone), je me suis dis que j’allais aussi installer l’application sur ma tablette pour éviter que cela ne se reproduise à l’avenir : que nenni ! Un seul périphérique peut être actif pour servir de double authentification.
Heureusement, d’autres services sont très vertueux et proposent de l’OTP, une application authentificator, des codes à usage unique à imprimer et à conserver dans un coin, les SMS, les clés de sécurités, etc.
#1.1
Pour ça que j’ai un boîtier physique de la banque pour l’OTP car je ne voulais pas leur app de merde et du coup j’ai la clef d’enrôlement en sécurité chez moi si je casse le boîtier, j’ai juste à en reprendre un autre (j’ai dit que mon smartphone n’est pas compatible ce qui est techniquement vrai vue qu’il est rooté, même si je peux masquer le root pour une application précise).
#2
J’ai même rencontré pire. Un service qui permet la création d’un mot de passe de n’importe quel longueur (par ex 20 caractères) mais qui n’enregistre que les 15 premiers sans prévenir. Résultat, je n’arrivais pas à m’authentifier. J’utilisais le mot de passe long de 20 caractères croyant que c’est bine celui qui avait été “enregistré”. Je n’ai trouvé l’astuce qu’après plusieurs réinitialisation de mot de passe.
#3
J’attends impatiemment la 2ème partie de l’article pour la session de “name and shame”
#4
Ca tombe bien, y’a https://neal.fun/password-game/ qui a été mis à jour très récemment…
Mais imposer des contraintes fortes aux mots de passes fait baisser l’entropie : si je dois mettre obligatoirement une majuscule et une minuscule et un chiffre et un caractère spécial, on sait déjà qu’il y aura ces 4 variations dans le mot de passe → on a plus d’information sur lui que si ce n’était pas imposé, mais suggéré.
#5
Rappelons aussi que le “l33tspeak” n’est pas une bonne idée : ce sont des patterns eux aussi testés par le brute force.
Un mot de passe ne doit pas être signifiant, et il doit être unique au compte auquel il est associé, perso c’est la seule chose que je préconise.
#6
Ce que je n’aime pas, ce sont les services qui stockent les mots de passe (ou leur hash) précédents pour empêcher de réutiliser un même mot de passe à nouveau. Ce qui, je le concède est une mauvaise pratique.
Mais. C’est rajouter une faille de sécurité supplémentaire pour les utilisateurs, pas pour le service en question, si cette base de données d’anciens mots de passe fuite.
Du coup, les services se protègent, mais ils ne protègent en aucun cas les utilisateurs.
#6.1
Je ne sais plus si c’était sur le site de support HPE, IBM ou Intel où j’ai récemment dû renouveler mon mot de passe, et dans les règles il y avait “ne pas réutiliser un des 15 derniers mots de passe”… oui, 15, ce n’est pas une faut de frappe
#7
Quand j’étais étudiant en 2005, on s’est rendu compte que le mot de passe du webmail de l’école d’ingénieur était tronqué à 8 charactères. Donc au quotidien cela fonctionnait avec plus et un jour, je tape le mot de passe à moitié, appuie sur “entrée” sans faire exprès et cela passe.
Et pour avoir testé ensuite en enlevant 1 charactère à chaque fois, puis en tapant les 8 bons premiers charactères et n’importe quoi après, cela passait.
Déjà à l’époque on a bien ri jaune.
#8
Il y a Proton pass qui arrive, mais quelles sont les garanties puisque il semble que le stockage en local ?
#8.1
Merci pour l’information, je l’avais pas vu passé ! Ça a l’air pas mal du tout :)
#9
Il manque aussi les questions/réponses comme qu’elle est votre couleur préférée, obligatoire chez Boursorama ou myedenred.
Pour moi ce sont des trous de sécurité si les utilisateurs répondent effectivement aux questions.
Heureusement j’ai pu y mettre des mots de passes forts comme réponses à ces questions.
#10
J’ai toujours été effaré par la saisie du mot de passe de ma banque:
Et ça choque personne….
#10.1
Le code d’accès de ta banque est limité en nombre de tentatives normalement. Dans mon cas au bout de trois le compte est verrouillé. Et pour déverrouiller c’est soit service client, soit appli smartphone.
Si ce n’est pas le cas, change de banque.
#10.2
Surtout que depuis une décennie, les trojans et compagnie font une capture d’écran du code bien visible au clique.
#10.3
Si tu actives la biométrie on ne voit pas le PIN 😉
Mais vous devez faire référence au CA, j’ai jamais compris pourquoi ils affichaient les chiffres à l’appui, c’est vraiment mal foutu je trouve en effet. Et d’ailleurs en règle générale, je n’aime pas leur application…
A la CE, c’est 8 caractères, touches bien plus petites, et pas d’affichage à l’appui, c’est assez facile de taper sans se faire voir même en public. Pour ça d’ailleurs que j’ai toujours pas activé la biométrie.
Après techniquement, une personne qui arrive à voir ton PIN, il faut encore qu’il trouve ton numéro de compte. Qu’il ajoute ton compte sur son smartphone avec une confirmation SMS ou securpass (a minima connexion sur nouveau périphérique ca doit envoyer un mail).
S’il y arrive, il aura besoin de ton securpass pour n’importe quelle transaction, donc il n’aura que la visu des comptes en fait. C’est le but de ce fameux securpass d’ailleurs, le risque est limité, mais j’avoue que c’est nimp ce PIN visible avec des grosses touches :)
#11
Oui, certains sites qui posent des questions de ce type pour “récupérer” son mot de passe, mais qui peuvent être relativement simple à contourner avec un peu de Social Engineering
#12
Et quand tu tapes ton code CB (4 chiffres) sur un DAB ou au supermarché, ça te choque ?
#12.1
Là c’est du 2FA (carte + code).
#12.2
Un peu comme un numéro de compte (en général masqué) et un code ?
Ma remarque était plutôt que lorsque je tape mon code de CB je fais en sorte de m’assurer qu’autour de moi personne ne regarde, je ne vois pas pourquoi il ne faudrait pas être aussi attentif pour se connecter à sa banque.
Enfin, je ne connais pas d’opération financière à réaliser en ligne avec sa banque qui soit si impérieuse qu’il faille les réaliser dans la rue. A titre personnel, toutes mes opérations bancaires, je les fait à mon domicile ou dans mon hébergement (hôtel par exemple) quand je suis en déplacement ?
#12.3
(Haa, je croyais avoir répondu, mon message à dû se perdre…)
Le numéro de compte est publique (il est sur un RIB que tu dois donner pour recevoir un virement par ex.) et il sert en effet souvent comme identifiant. C’est facile aussi de l’avoir au moment où tu te connecte (une petite photo/vidéo avec un smartphone discrètement…).
Mais ben5757 a mieux répondu, merci
#13
C’est la réalité. À chaque inter le type ne connaît pas son mot de passe et je dois le réinitialiser. À chaque inter on me demande de baisser la complexité minimum car 12 caractères sans rotation obligatoire c’est trop difficile. À chaque inter ça refuse de passer sur de l’auth matériel parce-que c’est trop cher de payer 40 balles par têtes. Je n’ai même plus d’empathie concernant ceux qui se font piquer leurs comptes, fallait pas utiliser «jenifer4» comme mot de passe.
On parle de certains sites officiels du gouvernement et des banques c’est ça ?
#14
Euh alors . Vous êtes entrain de dire que les banques qui utilisent encore ce système de pad virtuel à 6 chiffre comme seul moyen d authentification ne sont pas négligeante ?
Vous comparez avec l authentification par carte bancaire mais ce n est pas du tout la même chose. L’authentification par carte bancaire est une vrai authentification à plusieurs facteurs.
Pour rappel une authentification par plusieurs facteurs doit permettre à l utilisateur de fournir des éléments pour être authentifier. Il doit fournir au moins deux elements de types différents . Les types sont :
Dans le cadre d un paiement DAB, il y a bien deux facteurs . La carte est un élément que l on possède et le PIN est un élément que l on connait. Il s agit bien d une authentification à multiple facteur assez secure.
Vous semblez dire que le numéro de compte est un facteur d authentification. Non il s agit d un facteur d identification pas nécessairement secret ( facile d accès ) et ne saurait être utilisé comme élément d authentification. Et même si c était possible ce ne serait pas un multiple facteur d authentification car ce serait un élément que l on connaît comme le pin.
Le mécanisme de lockout rend compliqué le bruteforce mais ce type d authentification est très sensible au malware ou aux attaque par homme du milieu.
Et de toute façon la RGPD et la régulation bancaire PSD2 impose de ne plus utilisé ce type d authentification car il n y a pas de multiple facteurs.
Le blocage de compte est une mauvaise pratique qui ne doit pas être utilisé comme parade à une politique de mot de passe et d authentification merdique.
Bien que le blocage permette d éviter le bruteforce, il peut être détourner pour faire des attaques par déni de service.
Si en tant qu attaquant j arrive à bruteforce les identifiants , je peux imaginer un scénario où je scripte un robot qui fera des tentatives d authentification en boucle pour bloquer les comptes et crée une situation de déni de service pour les utilisateurs.
Quand j étais auditeur l authentification c était toujours gagnant
La bonne réponse n est pas de bloquer le compte mais de bloquer la source des tentatives et mettre un monitoring efficace pour permettre à la DSI de prendre des mesures.
De toute façon les mécanismes de blocage de compte ou de source ne protège pas les mots de passe contre plusieurs classes d attaque. C est pour ça que je dis que le PIn a 6 chiffres c est pas du tout une bonne pratique. Il est acceptable uniquement s il y a du multiple facteur. De préférence de type yubikey ou TOTP app à la rigueur. Pas de SMS par contre.
Si si ça m interpelle d autant que ce n est pas conforme avec les régulations modernes
#15
A supprimer : doublon
#16
Je trouve dommage que l article ne parle pas de la rotation des mot de passe de 90 jours imposée dans beaucoup d organisation.
C est à présent considèré, au moins par le NIST, comme une mauvaise pratique de sécurité car les utilisateurs réutilisent leur mot de passe en ajoutant un préfixe ou un suffixe qui sont souvent un incrément ou la date de changement de mot de passe.
#16.1
C’est déjà expliqué en détail dans les deux actus (en lien dans cet article) sur les recommandations de la CNIL et de l’ANSSI
#16.2
Ah je suis désolé je m étais arrête à l article
#17
Pour moi c’est un complément plus qu’une parade : X tentatives échouées, on bloque l’accès car potentiellement frauduleux. Cette méthode n’existe pas que dans le bancaire, à peu près toutes les gestions d’authent que j’ai connues en entreprise ont aussi ce mécanisme.
Ne travaillant pas à la DSI de ma banque, je ne suis pas en capacité de dire si cette mesure existe ou non. Bloquer la source est aussi une action complémentaire de mon point de vue. La réponse à un DDoS n’est pas que dans le bruteforce de l’authent, elle est générale sur un service en ligne (Azure en a encore fait les frais hier).
J’en profite pour poser une question, vu que tu semble avoir une bonne expérience sur le sujet, le clavier virtuel des portails des banques est-il attaquable par brute force ?
#18
Pour le clavier virtuel tu peux préciser ta pensée ? L anti bruteforce se situe côté serveur avec le mécanisme de blocage de compte. Tu penses à une attaque côté client ?
#18.1
Oui c’est ça, côté client où le formulaire de login ferait l’objet d’attaques automatisées.
#18.2
Je suis désolé mais je ne comprend pas le cas d usage . Tu peux expliquer ? Bruteforce à partir d où et pour quel objectif ?
Parce que si je suis un attaquant et que je veux récupérer des credentials côté client, il vaut mieux que j arrive à me mettre sur le poste client ou dans le navigateur de ma victime. Dans ce cas rien besoin de bruteforcer je dois juste attendre qu il entre le pin et récupérer les infos soit quand la requête part vert le serveur( peut être inutile si le pin sert à signer un challenge ) ou encore mieux directement en mémoire dans le navigateur. Ici même si le pin sert juste à résoudre un challenge à envoyer au serveur, il sera forcément un moment ou un autre manipuler en clair.
Je tape peut être à côté avec mon raisonnement mais je vois mal ce qu on peut accomplir avec un bruteforce côté client .
#18.3
Non rien d’aussi compliqué, juste savoir si le formulaire de connexion utilisé sur le portail d’une banque, celui qui fait apparaître le clavier virtuel, peut être attaqué par brute force (c’est à dire tests multiples d’accès) comme d’importe quel autre formulaire de login/password.
Car côté client oui, je sais qu’ils sont vulnérables aux keyloggers qui auraient la capacité de screenshot le clic pour récupérer le code.
Mais après c’est peut être pas un vecteur d’attaque. C’était justement ma question, désolé si je l’exprime mal
#19
Peux-tu élaborer ?
Je m’explique : Les banques ont “profité” du fait que les SMS n’étaient pas considérés assez sur pour imposer sur les smartphones leurs applis.
Or ces applis sont souvent catastrophiques : Elles réclament beaucoup trop de permissions, font énormément d’accès réseau, et souvent refusent de marcher sur les téléphones rootés (mais par contre marchent sur de l’android 4 non patché).
=> Bref, c’est typiquement un cas où j’ai l’impression qu’on a utilisé le prétexte de la sécurité (notamment les failles du SS7) pour imposer des applis nettement plus intrusives et au final plus dangereuses à long terme, sans compter le fait que ça exclu la possibilité d’utiliser les services en ligne avec un vieux téléphone 2G style nokia 3310 (qui reçois tj les SMS)
Et ce plutôt que de régler le vrai souci de sécurité & d’identification des source des SMS chez les opérateurs. Et qui donne d’ailleurs lieu encore aujourdhui à des campagnes de spam.
De plus face à de l’engineering social , ça n’a aucun intérêt ( https://www.youtube.com/watch?v=6Jv0EzXdQbk )
#19.1
Le problème de fond dans ton cas, ce n’est pas le SMS.
Les banques sont passées sur un système de sécurité qu’elles maitrisent de bout en bout, ce qui offre une bien meilleur sécurité qu’en passant par des tiers. Ca leur permet de mieux sécuriser et de faire “ce qu’elles veulent”, donc plus de réactivité, plus de simplicité, meilleur gestion des problèmes, etc… et non, pas plus dangereux à moyen ou long terme. Je ne vois pas comment elles auraient pu par exemple se mettre en conformité avec le DSP2 sans une application bancaire et avec du SMS.
Si le problème était juste le SMS et sa sécurité, elles auraient très bien pu aussi demander une activation 2FA standard via une application de notre choix.
Le problème de fond dans ce que tu décris, c’est plus le nombre de permissions de ces applications et les données qui sont récupérées par ce biais par les banques.
(Personnellement, venant de ma Banque cela m’importe peu)
#20
Ben il me semble que c’est possible si je lis ça :
https://www.banque-france.fr/stabilite-financiere/comite-national-des-moyens-de-paiement/faq-les-paiements-en-questions/les-changements-introduits-par-la-dsp2 (chapitre “
Le renforcement de la sécurité des paiements en ligne “)
Alors oui ça oblige la banque a supporter plusieurs systèmes. Mais le choix d’imposer une application reste un choix de leur part.
Et de plus, pour cette application c’est aussi un choix de leur part de refuser les téléphones rootés mais mis à jour comme d’accepter les téléphones non rootés mais sur un vieil android non patché…
Clairement le modèle de menace qu’ils envisagent me parait inadequat.
Ben tout dépends de la confiance que tu as dans la qualité de leur dev , de leurs process de gestion des risques & de leur réponse aux particuliers en cas de problèmes.
Et de mon point de vu le danger provient davantage de l’appli bancaire et des données que la banque collecte (et ce qu’elle en fait) que d’un hack ciblé sur moi & mon terminal.
#20.1
Oui c’est leur choix, mais comme je le disais, niveau sécurité c’est plutôt logique.
C’est quand même contradictoire ce que tu dis. Tu veux de la sécurité mais tu veux la possibilité d’installer une application bancaire sur un téléphone rooté. C’est contraignant pour toi qui a rooté le tient peu être, mais c’est du bon sens dans les faits.
Sinon, niveau confiance, je parlais des données bien sûr.
#21
Je ne peux pas répondre à ces questions. Je n’étais pas auditeur en France et le clavier numérique je ne suis jamais tombé dessus mais je dirais que oui c’est sensible comme tout autre authentification login/mot de passe. Sauf qu’ici t’es avec un mot de passe super faible. Autant dire que les mesures anti bruteforce sont vraiment nécéssaire.
Pour l’account locking je persiste à dire que ce n’est pas une très bonne méthode de protection et le risque de déni de service est connu et documenté au niveau des référentiel de sécurité logiciel. Deux exemples :
Je pense que ce n’est pas parce que des banques et des organisations utilisent ce mécanisme que c’est valide. La plupart des organisations obligent leurs utilisateurs à faire une rotation de mot de passe tous les 90 jours. C’est vraiment un antipattern bien documenté mais encore trop courant.
Perso je faisais des remarques à chaque fois qu’une app bancaire accepté les tel rooté . Mais je faisais également des remarques lorsqu’elle acceptait de s’installer sur des mobiles non supportés.
Concernant les permissions demandé je n’ai jamais vu d’abus et j’en ai analysé pas mal. Mais c’était à un instant ’t’ donc je ne prétends pas à l’exhaustivité des mon expérience. Mais je suis curieux tu as un exemple d’abus précis en tête ( sans forcément cité la banque ).
Concernant le SMS, il n’est plus considéré comme un facteur sécurisé pour les raisons que tu as
cité. Fragilité du protocole SS7 et fragilité des process de certains opérateurs qui permettait de faire du hijacking de carte SIM. Il y’a eu des affaires de wallet bitcoin volait qui ont largement contribué à jeter le discrédit sur ce facteur d’authentification. Il est plus facile je pense en tant que fournisseur d’identité et d’authentification de se débarrasser de cette méthode que de compter sur le fait que les opérateurs vont combler leurs lacune. En plus, Le NIST ne le recommande plus depuis au moins 2016. Ce n’est certes pas une autorité faisant fois ici mais leur recommandations finnissent souvent par arriver chez nous quand même.
#21.1
Merci pour les liens, l’argumentaire est intéressant et je n’avais pas connaissance des effets de bord induits par cette méthode.
Ce n’est pas non plus ce que j’ai voulu dire. J’ai constaté ce pattern à peu près partout en dehors des services en ligne. En entreprise j’ai toujours vu le SSO verrouiller un compte au bout d’une dizaine de tentatives échouées. D’où le fait que je considérais cette pratique comme étant un standard.
Pour le second point on est d’accord, j’ai aussi toujours considéré que c’était une mauvaise chose car induisant le risque de mots de passe à pattern déductible et autre post-it sur écran.
#22
Bonjour,
Ayant lu l’article avant la mise à jour, je trouve difficile de trouver ce qui a été mis a jour… du moins sur mobile.
Ne serait-ce pas possible de mettre en valeur le contenu mis à jour ? Soit directement soit via un sélecteur en tête d’article pour ceux qui ne voudrait pas avoir cette mise en valeur visible de base.
Merci d’avance
#23
Autrefois les ajouts et modifications étaient dans une autre couleur.
#24
Ben le problème c’est que si une appli (bancaire ou autre) n’accepte QUE les téléphones supportés par les constructeurs (cad, pour moi, avec des maj de sécu régulière) , ben clairement vu l’état actuel du parc , soit tu obliges tes clients à changer de téléphone tous les 2 ans, soit tu élimines beaucoup de clients. Effectivement, la seule solution serait d’obliger les constructeurs à faire 5 ans de mises à jour…. (et comment s’assurer qu’ils font bien ces correctifs de sécu… ?)
C’est - à mon sens - là que le root de téléphone que VOUS considérez comme si dangereux est pour moi un point très positif : les OS alternatif genre linéage , eux, proposent des maj régulières pour tous les téléphones supportés et un mécanisme d’OTA - les tél rootés sont bien plus à jour que OS des constructeurs. Et ça permet justement de redonner vie à un tél qui sinon aurait fini à la poubelle.
Alors oui je comprends bien que dans l’absolu c’est pas dans l’intérêt des constructeurs (ni des banques, ni des opérateurs). Mais pour les gens c’est un avantage, pas un inconvénient.
En plus les téléphones récent signalent assez fortement que le téléphone est rooté (au démarrage avec un gros message en rouge ou orange). La manipulation pour passer le tel en debug , déverrouiller le bootloader puis installer une nouvelle image est quand même pas si triviale au point que la banque ait peur que jojo puisse le faire.
Je n’ai pas d’app bancaire sur mon téléphone.
Mais à une époque celle de La Poste demandais absolument toute les permissions possible - au point que je me suis demandé si c’était pas un stagiaire qui avait rempli le manifeste - les permissions en question n’étant pour la plupart jamais utilisés par l’appli (mais aurait pu l’être par une maj , du coup).
Il y avait notamment celle de “recouvrir” une autre app, la géoloc bien sur, le fait de remplacer l’app de messagerie, …
Mouais.
Donc en fait c’est ce que je pensais , les banques se défient des opérateurs en les considérant incapable de fixer la sécurité de leurs réseaux et préfèrent faire des appli elles-même, avec N niveaux de sous-traitance.
Je me demande bien en qui j’ai le plus confiance… :-/
J’ai l’impression que les banques imaginent des hackers internationaux comme dans les films qui infiltrent des programmes espions secrètement dans le coeur des réseaux des opérateurs et profite des téléphones rootés pour voler les tokens bancaires.
Alors que la majorité des “hack” c’est une alloteuse qui est assez habile en social engineering pour que mme michu lui file son code de l’appli bancaire par tel…
#24.1
Il est possible d’avoir une ROM custom sans activer le root.
C’est même recommandé d’un point de vue sécurité.
Mais je chipote : ça ne suffit pas pour avoir un statut SafetyNet valide.
Cela dit, je me rappelle que quand j’utilisais LineageOS sans les applis Google, mais non rooté, l’application de La Banque Postale fonctionnait.
C’était en 2019, sur un Nexus 5X (je ne sais pas si c’est toujours possible aujourd’hui).
#25
Je parlais de Boursorama et la biométrie depuis un laptop / desktop c’est difficile
Ça fait un moment que leur clavier visuel n’est plus sécurisé (visible / troyan qui fait une capture d’écran au clique etc) et surtout ça limite la complexité du mot de passe.
#26
Excuse moi de te le dire comme ça mais tu as une sacré imagination pour ton dernier paragraphe. Tu fais un petit peu une fixette sur les banques non ? Pour les SMS, je n’ai pas dit que c’était les banques qui imposaient leur retrait. Leur retrait est imposé dans certains standard de sécurité qu’elles ne sont pas obligé de suivre. Pas mal de banque sont toujours friante du SMS alors que c’est vraiment un facteur d’authentification faible. Paypal me fait toujours de l’OTP par SMS. J’avais même auditer une banque qui reposait toute son authentification là dessus ( même pas de mot de passe). Elle n’a pas des masses apprécié ma remarque sur le sujet.
Tu parles comme si c’était les banques qui faisait la pluie et le beau temps en sécurité en terme de sécurité. Ce n’est pas le cas elles les subissent. Si elle pouvait donner des login mot de passe croit moi qu’elle le ferait c’est moins cher.
Concernant les téléphone rootés ça se discute. Pour moi le danger c’est que ça pétait ( j’utilie le passé parce que ça fait longtemps que je n’ai pas regardé ) la ségrégation et le système de permission entre application et ça représente un risque réèl. Mais croit mois que certains faisaient bien la tête quand ils voyaient ce finding parce que ça coute vraiment cher de faire la détection de root directement.
Pareil pour les vieux téléphones, ce n’était pas du tout un finding qui les arrangeait. Et je tiens à préciser que les remarques que je mettais dans les rapport n’étaient pas obligatoirement suivis. Je faisais juste mon travail de remonter les vulnérabilités. Et oui parfois les remédiation ont des conséquences sur l’utilisabilité.
Je ne suis pas un fan du secteur financier. Mais il n’y a pas “les banques”. Elles n’ont pas toutes le même niveau de sécurité et n’appliquait pas toutes les recommandations de la même manière. C’était une question de risque, de politique interne et bien sûr de régulation :) .
Pour la poste je suis pas étonné tiens
#27
Puisqu’on parle des banques, j’ai regardé un peu ce que font les banques françaises en termes d’authentification (code à 6 chiffres vs mot de passe) :
Clavier visuel (6 chiffres)
Mot de passe
Clavier visuel (6 chiffres)
Subtilité : BforBank demande aussi la date de naissance pour pouvoir se connecter
Clavier visuel (6 chiffres)
↳ Boursorama banque (filiale de la SG) :
Clavier visuel (8 chiffres)
(on gagne 2 chiffres, woohoo)
Mot de passe
Clavier visuel (6 chiffres)
↳ Ma French Bank (filiale de LBP) :
Mot de passe
Clavier visuel (6 chiffres)
Subtilité : il fallait en saisir seulement 3 (un pattern du style [ _ • _ • • _ ] était affiché).
Ça fait quand même beaucoup de claviers visuels, et de codes à 6 chiffres.
Visiblement, la CNIL autorise les banques à avoir des codes composés de chiffres uniquement (5 chiffres et plus), du moment qu’il y a :
+
ou
Identification du terminal de l’usager (ex. : adresse IP, adresse MAC…)
Bien sûr, depuis l’entrée en vigueur de la directive DSP2, une “authentification forte” est imposée.
Et de ce point de vue là, la liste est plus simple : toutes les banques que j’ai mentionnées ci-dessus acceptent le SMS comme second facteur (notamment pour ceux qui n’ont pas de smartphone), sauf :
Ce n’est pas le cas des autres filiales – Fortuneo, Monabanq et Cofidis – qui acceptent le SMS.
#27.1
C’est complet. Merci :)
Juste un petit mot pour compléter sur la double authentification (différent de l’authentification forte !). Je parle pour le CA et la BRED (mais peut être pour d’autre aussi), elle n’est pas requise à chaque fois si lors de la connexion, on choisi un ordinateur privé et non un ordinateur publique.
On a une authentification à 2 facteurs lors de la première authentification. Ensuite, si c’est depuis le même navigateur, seul le mot de passe est demandé, pendant une durée de 3 mois (et après, il faut revalider à l’aide de 2 facteurs).
#27.2
Au Crédit Mutuel,c’est paramétrable :
#27.3
Correction : Le Crédit Mutuel autorise le SMS (l’ayant utilisé hier, je confirme que ça marche toujours).
C’est peut-être uniquement chez les anciens clients ou sous autres contraintes dont je n’ai pas connaissance mais c’est possible.
#27.4
Quel Crédit Mutuel ? Au CMNE, c’est appli obligatoire…
#27.5
CM Anjou.
#27.6
Pareil à la Caisse d’Épargne, appli soit-disant obligatoire, mais si tu ne l’installes jamais ça reste avec des SMS.
#28
Quand il y a de l’authentification à 2 facteurs, la plupart des services permettent de mémoriser l’appareil, pour ne pas avoir à saisir le 2ème facteur systématiquement.
J’ai rarement vu des services qui n’offraient pas cette possibilité (que ce soit des gestionnaires de mots de passe, des fournisseurs d’email, …).
Pour les banques, le délai maximum entre 2 saisies du second facteur est de 90 jours.
#29
Pour le Crédit Mutuel, j’avais trouvé cet article, daté de début 2021 :
https://www.creditmutuel.fr/cmne/fr/le-mag/dsp2-authentification-renforcee.html
Et cette page : https://www.creditmutuel.fr/cmne/fr/dsp2-digipass.html
Mais j’avoue que je ne suis pas client chez eux, et peut-être que certaines branches du Crédit Mutuel autorisent toujours le SMS comme second facteur, effectivement.