Journal Sécurité et authentification des sites bancaires.

19
20
mar.
2017

Bonjour,

dernièrement alors que je me connectais à mon interface client sur le site de ma banque (ING Direct), je me suis posé la question de la robustesse de leur système d'authentification.

En effet pr se connecter et s'authentifier il faut :

  • étape 1 : donner son compte client, et sa date de naissance
  • étape 2 : donner 3 chiffres, sur les 6 que composent son code secret. Les 3 chiffres à donner variant à chaque nouvelle connexion, ie le système demande par exemple les chiffres en position (1,4,6) puis la fois suivante (2,3,5) etc… via un clavier virtuel.

Le tout étant encapsulé dans du https/SSL évidemment.

J'ai pas fait de calcul, mais j'ai trouvé après réflexion assez faible (au moins en apparence, ce n'est que mon avis de profane). Les infos demandées en étape 1 étant assez facile à trouver (ex. un employé mal intentionné). Et pour l'étape 2, là où les autres banques demandent 6 chiffres, ING n'en demande que 3, ce qui avec un peu de chance pourrait être trouvé (après je pense qu'ils doivent bloquer après 3 tentatives infructueuses).

Pour aller plus loin dans ma réflexion, je me suis posais la question suivante :

  • pourquoi les banques n'autorisent elles pas les mot de passe avec une suite de caractères (chiffres, lettres, symboles) ? (Je me doute que derrière ça doit avoir un impact sur les gros systèmes qui hébergent les applis métier)

  • pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

Voilà je me posais ces questions.

  • # N'importe quoi ....

    Posté par . Évalué à 10 (+10/-0).

    L'histoire de 3 chiffres sur 6 du code secret, c'est vraiment passer son temps à pourrir la vie de l'utilisateur (à moins que je naie pas compris ce que tu décris). Pourquoi compliquer la vie de l'utilisateur à lui demander de compter le 3eme chiffre, le 5eme ou le 6eme d'une série de chiffres ? C'est vraiment un truc à s'autogénérer des appels à l'assistance en ligne (surfacturée ?).

    J'espère que cette façon débile de faire ne va pas se généraliser : les claviers virtuels sont déjà assez pénibles comme ça. si c'est pour en plus ajouter une complexité

    • [^] # Re: N'importe quoi ....

      Posté par . Évalué à 3 (+2/-0).

      Tu as bien compris le système. Pr moi ce n'est pas ça le plus gênant, quand tu connais ton code par coeur, tu retrouves assez facilement les chiffres demandés. Encore une fois c'est plutôt le niveau de sécurité derrière qui pose problème selon moi.

    • [^] # Re: N'importe quoi ....

      Posté par . Évalué à 10 (+10/-0).

      J'imagine que ça permet de ne pas se faire intercepter son code en une fois au cas où ça se produit. Choisir 3 chiffres parmi 6 donne (si je ne me trompe pas) 20 combinaisons, ce qui fait que quelqu'un qui te voit taper ton code dans un cybercafé ou qui arrive à l'intercepter n'a qu'une chance sur 20 de pouvoir le reproduire.

      les claviers virtuels sont déjà assez pénibles comme ça. si c'est pour en plus ajouter une complexité

      On peut toujours discuter des détails, mais je ne pense pas que les banques ou autres organismes n'aient pour unique but dans la vie que de pourrir ton expérience utilisateur avec leurs services, c'est même probablement le contraire. Il faut quand même comprendre que l'équation est extrêmement difficile à résoudre : on veut des moyens de payement les plus fiables, les moins chers, les plus rapides, les plus sécurisés, et les plus faciles à utiliser possible. Par exemple, à titre personnel, je n'ai jamais compris l'intérêt des cartes sans contact, mais à voir le nombre de gens qui trouvent ça génial et qui réclament ce type de services aux commerçants, je me dis que je ne représente pas du tout la majorité. Comme on veut par dessus tout que la banque couvre les fraudes (à raison la plupart du temps, mais aussi en cas de négligence), il parait quand même assez normal que les banques trouvent un compromis entre l'achat en un clic et le chèque de banque. C'est certain que la multiplication des systèmes d'identification un peu baroques (code SMS, email, code partiel, claviers virtuels…) est un peu déroutante et semble parfois inefficace, mais comme on ne veut pas non plus de puces implantées sous la peau, il faut bien quand même une solution intermédiaire en terme de complexité.

  • # token ?

    Posté par . Évalué à 2 (+0/-1).

    Je ne sais pas ou en est le support des token hardware open source d'authentification sur les navigateurs web. Cela serait déjà une authentification forte en plus du mot de passe.

    "La première sécurité est la liberté"

  • # Un monde

    Posté par . Évalué à 2 (+2/-0).

    En lisant ton nal, j'ai du sourire. En Suisse, je ne connais aucune banque qui n'ai pas au minimum une authentification en 2 étape avec liste à biffer. Beaucoup de banques vont même plus loin en validant le contrôle avec une app mobile spécialisé comme par ex. photoTAN ou un "Mobile ID" qui permet de s'authentifier de manière sécurisée avec son téléphone mobile en utilisant une fonction dédiée de la carte SIM.

    • [^] # Re: Un monde

      Posté par . Évalué à 9 (+9/-2).

      comme par ex. photoTAN ou un "Mobile ID" qui permet de s'authentifier de manière sécurisée avec son téléphone mobile en utilisant une fonction dédiée de la carte SIM.

      La belle affaire.
      Grâce à cette merveille, tous ceux qui accèdent à leur banque sur leur mobile et qui ont leur 2FA sur mobile donnent toutes les clés à l'attaquant. Reste plus qu'à se servir.

      • [^] # Re: Un monde

        Posté par . Évalué à 5 (+5/-0).

        Bien sur, si je te donne un coffre en carton dont la porte est ouvert, tu n'as qu'à te servir. Si ce coffre est blindé et la porte fermée cela devient un peu plus difficile…

        Avec photoTAN, il n'est pas possible d'accéder à la banque sur le mobile. Il sert de validation d'un accès sur un ordinateur ainsi que pour la validation des paiements. Il nécessite une configuration initiale afin de "lier" le compte. Par la suite, lors de l'authentification sur l'ordinateur, une matrice de points est affiché. Celle-ci doit être scannée avec PhotoTAN qui retourne un code qui doit être saisi sur l'ordinateur.

        Avec le Mobile ID (dont il faut également une configuration initiale, chez l'opérateur téléphonique) il est possible de se connecter avec le même appareil sur le compte bancaire. Le Mobile ID est cependant protégé par un mot de passe séparé. De plus, la validation se fait par l'intermédiaire de la société de télécommunication. Pour ceux que ça intéresse, voici le document de référence technique (en anglais)

        • [^] # Re: Un monde

          Posté par . Évalué à 2 (+1/-1).

          Avec le Mobile ID (dont il faut également une configuration initiale, chez l'opérateur téléphonique) il est possible de se connecter avec le même appareil sur le compte bancaire. Le Mobile ID est cependant protégé par un mot de passe séparé. De plus, la validation se fait par l'intermédiaire de la société de télécommunication. Pour ceux que ça intéresse, voici le document de référence technique (en anglais)

          Si tu regardes ta spec, la faille se trouve sur le terminal à l'entrée du pin.
          Suffit que l'attaquant contrôle le terminal pour keylogger le pin, réutiliser le pin ou présenter une transaction autre pour le faire valider avec le pin de l'utilisateur.

          C'est pour ça que les tokens hardware les plus sécurisés ont leur propre clavier et un écran séparé pour saisir et présenter la transaction, sans possibilité de détournement.

          • [^] # Re: Un monde

            Posté par . Évalué à 2 (+2/-0).

            Tout à fait d'accord, le terminal peut être compromis. Ce qui est intéressant c'est que la sécurité prend également en compte l'utilisateur. Le terminal n'apparaît que et uniquement que lorsque la 1ère authentification à été faite sur le site internet de la banque, car c'est la banque qui envoie la demande pour le 2ème niveau. Si l'utilisateur n'est pas devant son pc il va très vite remarquer que quelque chose cloche.

    • [^] # Re: Un monde

      Posté par . Évalué à 6 (+5/-0).

      L'authentification 2 facteurs est une obligation légale pour les banques en Suisse. Le régulateur français est beaucoup moins regardant.

      • [^] # Re: Un monde

        Posté par . Évalué à 1 (+1/-0).

        C'est à vérifier, mais il y a une directive européenne (2007/64/CE probablement actualisée ou remplacée depuis) qui doit bien avoir 10 ans qui traite ce sujet. Elle a eu une transposition en droit français, mais j'ignore si la transposition contient cette partie (petite recherche à faire pour retrouver les références des textes et leur contenu).

      • [^] # Re: Un monde

        Posté par (page perso) . Évalué à 1 (+2/-1).

        Je ne sais pas si c'est une obligation légale, mais VISA et Mastercard refusent de travailler avec toi si tu n'est pas certifié PCI-DSS, et cette norme impose l'utilisation du 2FA, donc…

        • [^] # Re: Un monde

          Posté par (page perso) . Évalué à 3 (+2/-2). Dernière modification le 22/03/17 à 12:00.

          Ha, une norme qui impose une authentification à deux facteurs, mais qui considère comme valide la date de naissance comme second facteur, quelle blague…

          Autant que je sache, deux facteurs, c'est censé signifier des éléments d'authentification parmi deux de ces trois catégories :

          • quelque chose que l'on sait (typiquement, un mot de passe) ;
          • quelque chose que l'on est (typiquement, une empreinte digitale) ;
          • quelque chose que l'on a (par exemple une carte à puce, un générateur de codes, une grille de codes ou un téléphone).

          Le premier facteur est presque systématiquement un mot de passe. Selon les banques, le second facteur peut être un générateur de codes, un téléphone (par envoi d'un SMS, avec une sécurité discutable), une grille de codes (le plus sûr à ma connaissance, et accessoirement sans doute le moins cher) ou la date de naissance du client. Cette dernière est une vaste blague, parce qu'elle n'est absolument pas liée au corps ou à la propriété du client, mais clairement à la connaissance (en plus assez partagée), ce qui en fait un second premier facteur, et certainement pas un second facteur valide.

          À noter qu'une authentification à deux facteurs peut très bien utiliser un unique moyen technique, par exemple une carte à puce pourvue d'un code : pour l'utiliser, il faut dont posséder la carte, et connaître son code. Par rapport à un mode de passe, cela a l'avantage que ce code n'est jamais transmis, pas même à la banque, et que celle-ci pourrait très bien ne pas le connaître.

          • [^] # Re: Un monde

            Posté par . Évalué à 2 (+0/-0).

            Ha, une norme qui impose une authentification à deux facteurs, mais qui considère comme valide la date de naissance comme second facteur, quelle blague…

            Juste par curiosité, c'est dans quelle partie de PCI-DSS que la date de naissance est valide comme second facteur ?

            • [^] # Re: Un monde

              Posté par (page perso) . Évalué à 1 (+0/-2).

              Aucune idée, mais des banques utilisent ça comme prétendu second facteur, donc si elles sont censées respecter cette norme, soit c'est dedans, soit elles ont réussi versé un bon pot-de-vin à l'auditeur qui a vérifié leur conformité.

              • [^] # Re: Un monde

                Posté par . Évalué à 3 (+1/-0).

                Dans ce cas parle des banques, pas de la norme, d'autant que les banques ne sont pas obligées de s'y conformer https://fr.wikipedia.org/wiki/Norme_de_s%C3%A9curit%C3%A9_de_l%E2%80%99industrie_des_cartes_de_paiement#Conformit.C3.A9_et_validation_de_conformit.C3.A9

              • [^] # Re: Un monde

                Posté par . Évalué à 3 (+1/-0).

                Je ne suis pas spécialiste PCI DSS, donc j'ai été voir la norme (pci_dss_v3-2_3_fr-FR.pdf assez facilement trouvable sur le site PCI DSS).

                Les exigences sur les comptes sont décrites au chapitre 8 (page 79 et plus).
                Cela commence par une petite note :

                Ces obligations concernent tous les comptes, y compris ceux des points de vente, avec une capacité administrative, et tous les comptes utilisés pour voir ou accéder aux données de titulaires de carte ou pour accéder à des systèmes comportant ce type de données. Ceux-ci comprennent les comptes utilisés par les fournisseurs et les autres tiers (par exemple, pour l’assistance ou l’entretien) Ces conditions ne s’appliquent pas aux comptes utilisés par les consommateurs (comme les titulaires de cartes).

                Il n'y a a priori pas d'exigences d'authentification forte pour les utilisateurs des cartes demandée par le standard. Pour les utilisateurs (les salariés, en gros) du système manipulant les données, c'est par contre autre chose.

                Par ailleurs, en 8.2, on trouve en définition d'une authentification multifacteur :

                • Quelque chose de connu du seul utilisateur, comme un mot de passe ou une locution de passage ;
                • Quelque chose de détenu par l’utilisateur, comme un dispositif de jeton ou une carte à puce ;
                • Quelque chose que vous détenez, comme une mesure biométrique.

                J'en déduis que le consortium sait ce qu'est une authentification multifacteurs.

          • [^] # Re: Un monde

            Posté par . Évalué à 3 (+2/-0).

            À noter qu'une authentification à deux facteurs peut très bien utiliser un unique moyen technique, par exemple une carte à puce pourvue d'un code : pour l'utiliser, il faut dont posséder la carte, et connaître son code. Par rapport à un mode de passe, cela a l'avantage que ce code n'est jamais transmis, pas même à la banque, et que celle-ci pourrait très bien ne pas le connaître.

            Et ça a l'inconvénient qu'il n'est pas possible de réellement vérifier le mot de passe, car seule la carte peut dire si oui ou non le code est valide. Donc une fraude à la carte bancaire qui se fait, c'est de mettre la puce de la carte volée dans une autre carte derrière un microcontrôleur qui passe toutes les données du terminal à la puce de la carte volée, et les données de la puce volée au terminal. Sauf la demande de vérification du code que le microcontrôleur de transmet pas, il répond lui-même que c'est OK. La version moderne de la yescard.

            • [^] # Re: Un monde

              Posté par (page perso) . Évalué à 2 (+0/-0).

              Sic'est bien fait c'est un peu plus compliqué que ça, hein. La carte bancaire peut signer ses réponses avec sa clé privée qui est stockée dedans et à laquelle tu n'as pas accès.
              Je ne sais pas s'il y a des moyens de contourner, mais c'est probablement quand même un petit peu plus complexe que ça.

              • [^] # Re: Un monde

                Posté par . Évalué à 3 (+2/-0).

                Mais ça ne l'est pas (voir par exemple http://securite-elec.irisa.fr/2016/AssiaTria_fr.html).

                Clairement, ce ne sont pas les moyens techniques pour corriger qui manquent (on peut tout simplement dire à la carte de ne pas répondre si le pin est faux/n'a pas été vérifié) mais ici c'est le problème de la norme EMV qui est merdique et super chiante à faire évoluer pour corriger.

                Et oui, c'est un peu effrayant.

          • [^] # Re: Un monde

            Posté par . Évalué à 2 (+0/-0).

            Par rapport à un mode de passe, cela a l'avantage que ce code n'est jamais transmis, pas même à la banque, et que celle-ci pourrait très bien ne pas le connaître.

            Cela a un autre avantage, pour les utilisateurs, c'est que cela permet de limiter les exigences de dureté sur le mot de passe en question car :

            1. on a à peu près confiance dans la carte pour le garder secret, même sous la torture;
            2. on a à peu près confiance dans la carte pour le cramer, après X tentatives de suite pour le deviner (enfin, surtout pour cramer la clef privée protégée par ce code pin quand c'est bien fait).
    • [^] # Re: Un monde

      Posté par (page perso) . Évalué à 2 (+2/-0).

      Les banques Françaises aussi font du 2FA ; elles valident par SMS les opérations « monétaires », mais il est vrai que tu peux consulter les relevés de compte avec le mot de passe seul…

      Et en l'occurence, la solution d'ING direct, j'ai également moyennement confiance. Cependant, à la première connection sur un nouveau navigateur, il te demande ton numéro de contrat également (qui doit pas être stocké directement), ça évite de le taper (keyloggers) et cela limite un peu les attaques du coup. Après seulement, une fois le navigateur reconnu la date de naissance et les 3 chiffres suffisent. Mais un numéro de contrat, c'est comme un login, ce n'est pas fait pour être gardé secret.

  • # 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

    Posté par . Évalué à 10 (+14/-0).

    Pour que la banque puisse demander 3 chiffres sur 6, il faut qu'elle ait stocké chacun des 6 chiffres dans sa BDD. En effet, en temps normal, tu demandes un seul mot de passe à l'utilisateur, tu le haches, tu compares le hash à celui qui est dans ta BDD, si ça correspond, c'est bon, l'utilisateur est authentifié. Ceci permet de ne pas stocker de mot de passe en clair dans ta base de données.

    Mais pour pouvoir demander les chiffres 1, 2 et 5, il faut que les chiffres 1, 2 et 5 soient dans ta BDD. De cette façon, tu peux demander à l'utilisateur les chiffres 1, 2 et 5 de son code, tu haches chaque chiffre, et tu compares le hash du chiffre 1 avec celui de ta base de données, idem pour le hash du chiffre 2 et celui du chiffre 5.

    Au final, tu as donc stocké 6 hashs (un par chiffre) de 1 chiffre chacun. Le problème, c'est que ça facilite fortement l'attaque, le jour où ta BDD fuite.

    En effet, on ne sait pas retrouver facilement l'antécédent d'un hash donné. La seule façon de faire est de calculer tous les hashs de tous les antécédents possibles et de les comparer à la BDD. C'est long, surtout si on a choisi une fonction de hash un peu lente. La question est donc : combien d'antécédents sont possibles ? Autrement dit, combien de mots de passe sont possibles ?

    Pour un mot de passe de 6 chiffres de 0 à 9, la réponse est simple : il y a 106 possibilités. C'est peu. Mais c'est déjà bien plus que pour le mot de passe divisé en 6 chiffres stockés séparément ! En effet, pour retrouver le premier caractère, l'attaquant n'aura qu'a hacher les chiffres de 0 à 9 jusqu'à trouver le bon. Idem pour le second caractère. Et ainsi de suite. Un attaquant qui a accédé à la base de données des mots de passe n'a donc que 10 hashs à calculer. Si le concepteur a été prudent et a combiné une chaîne de caractères aléatoire (stockée dans la même base de données) au chiffre et a pris 6 chaînes de caractères différentes (une par chiffre), alors on monte péniblement à 60 hashs.

    Autrement dit, on vend à l'utilisateur un faux sentiment de sécurité ("c'est plus compliqué à utiliser, c'est donc forcément plus sécurisé") qui aboutit en pratique à diminuer la sécurité.

    Ça, ce sont les sources. Le mouton que tu veux est dedans.

    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

      Posté par . Évalué à 3 (+2/-1).

      Pour un mot de passe de 6 chiffres de 0 à 9, la réponse est simple : il y a 106 possibilités. C'est peu. Mais c'est déjà bien plus que pour le mot de passe divisé en 6 chiffres stockés séparément ! En effet, pour retrouver le premier caractère,

      Ah bon ? Moi j'ai une banque stupide qui a forcé le changement de mots de passes en ajoutant 2 digits, mais toujours uniquement par des chiffres, et en ajoutant une nombre de répétition max de digits et sans séquences. (ce qui re-réduit l'espace des possibilités)

      Tester l'entropie au lieu de mettre en places des règles bancales à la con, on en est encore loin.

      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

        Posté par . Évalué à 5 (+3/-0).

        Tester l'entropie au lieu de mettre en places des règles bancales à la con, on en est encore loin.

        Oui et non. Si tu enlèves les règles qui complexifient les mots de passe mais diminue l’entropie, combien d’utilisateur de ta banque vont choisir 123456, leur date de naissance (12 par rapport à 99 ça fait quoi comme entropie ?), etc.

        Je pense que les responsables de sécurité des banques ne réfléchissent pas que en entropie pur, mais en risque. Le fait que ça baisse l’entropie, ils le savent probablement, mais ils augmentent malgré tout la sécurité globale.

    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

      Posté par . Évalué à 2 (+2/-2).

      Autrement dit, on vend à l'utilisateur un faux sentiment de sécurité ("c'est plus compliqué à utiliser, c'est donc forcément plus sécurisé") qui aboutit en pratique à diminuer la sécurité.

      Suffit de constater le nombres de personnes qui croient que le "3D Secure" des cartes bancaires augmente la sécurité du possesseur de la carte. J'ai jamais eu une réponse dans le sens contraire.

    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

      Posté par . Évalué à 3 (+3/-2).

      Au final, tu as donc stocké 6 hashs (un par chiffre) de 1 chiffre chacun.

      Tu peux stocker 20 hashes de 3 chiffres (un par combinaison), je ne suis pas certain du tout que ça facilite une attaque éventuelle…

      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

        Posté par (page perso) . Évalué à 4 (+2/-0).

        20*10^3 = 20000 (si sel différent, sinon 10^3 une seule fois) et un assemblage comme on le fait pour séquençage d'ADN (Mais en beaucoup plus simple) vs 10^6 = 1000000. Cela change d'un bon facteur \frac{1000000}{20000} = 50 fois. Le facteur empire avec la taille du code.

        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par . Évalué à 1 (+0/-0).

          Est-ce que ça tient compte du fait que chaque code est dépendant de la question ? (s'ils demandent le 1er, 2ème et 3ème chiffres ou le 4ème, 5ème et 6ème chiffres, le bon code sera différent)
          Au final, les "bons codes" sont plutôt 6 chiffres: les 3 chiffres de la question + les 3 chiffres de la réponse. (et il me semble que le principe de hashage+sel fait que la connaissance des 3 chiffres de la question n'aide pas réellement)

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par (page perso) . Évalué à 2 (+0/-0).

            Le hashage est surtout là comme une protection en cas de vol de DB. Dans ce cas, le protocole de discussion avec le client (chiffres demandés, …) n'a aucune importance. Le sel aide principalement à protéger contre les tables pré-calculées…

            Si tu as la DB, tu obtiens facilement le mdp. Et donc, le protocole client est cassé.

            Bref, quoique tu fasses, le système est merdique (Indépendamment de la taille du mdp).

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par (page perso) . Évalué à 2 (+0/-0).

              En cas de vol de CB, certaines banques permettent de dévalider cette CB avec l'application pour smartphone immédiatement. Des fois c'est pratique, et plus rapide que de retrouver le bon numéro pour faire opposition, avec toutes les données justificatives à fournir …

              Speed dating is useless. 30s isn't long enough to explain the benefits of functional programming in Haskell

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par . Évalué à 2 (+2/-1).

              Je ne suis pas sur de comprendre.

              Si on vol la DB, on a les 20 hash.
              Tu fais quoi ensuite ?

              Réduisons le problème à 2 questions au lieu de 20:
              le mot de passe est 789123
              première question: "entrez le premier, troisième et cinquième chiffre".
              Le bon code est: 792. Je prends: 135792 (les trois chiffres de la question, les trois chiffres de la réponse). Je rajoute un sel et obtient un hash et ça me donne par exemple AAAAAA. Je le sauve dans la base de donnée.
              deuxième question: "entrez le premier, troisième et sixième chiffre".
              Le bon code est: 793. Je prends: 136793 (les trois chiffres de la question, les trois chiffres de la réponse). Je rajoute un sel et obtient un hash et ça me donne par exemple BBBBBB. Je le sauve dans la base de donnée.

              Lorsque je veux tester si le client a entré le bon code, je prends les 3 chiffres de la question + les trois chiffres de la réponse, je rajoute le sel et obtient le hash. Si le résultat est AAAAAA ou BBBBBB, c'est que le code est bon (je n'ai même pas besoin de retenir que AAAAAA correspond à la question un, car s'il n'y a pas de collisions, impossible que le hash de la question deux puisse correspondre à un hash obtenu avec une question un).

              Tu noteras que prendre les trois chiffres de la question n'est qu'un exemple: en pratique, avec juste la base de données, tu ne sais pas ce qui est fait: à la place de 135 pour la question un, il se peut qu'on utilise 531, ou 001 ou n'importe quel identifiant associé en dur à "question un" dans le protocole.

              Comment fais-tu à partir de AAAAAA ou BBBBBB pour pouvoir répondre à, disons, la question un (tu ne peux pas savoir si AAAAAA ou BBBBBBB correspond à la question un, vu que comme expliqué, il n'est pas nécessaire pour la banque de le savoir et donc elle les a mélangé lors de leur création) ?
              Pour la question un, même si tu connais le début (mais comme expliqué, il n'y a aucune raison pour que ce soit le cas), il te faut trouver 792. Tu ne peux pas comparer AAAAAA et BBBBBB avec toutes les combinaisons 792000 792001 792002 … à cause du sel.

              Comme dit par ailleurs, au final, cela revient simplement à donner au client 20 mots de passe différents. Vu que dans le système en question, la force brute est inutile (car plusieurs essais finiront par lancer une alerte et bloquer la carte) et le réel danger est l'interception du mot de passe initial (789123), la solution me parait plutôt intelligente.

              • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                Posté par (page perso) . Évalué à 1 (+0/-1). Dernière modification le 20/03/17 à 16:57.

                Si on vol la DB, on a les 20 hash.
                Tu fais quoi ensuite ?

                simple. J'ai à ma dispo. le hashing de toutes combinaisons en 3 chiffres (et leur position sinon ils peuvent pas checker):

                000 ->
                001 ->
                002 ->

                Je saurai donc que le pass est

                x0x1x4
                10x14x
                xx21x4

                -------------------------
                102144

                135792 (les trois chiffres de la question, les trois chiffres de la réponse)

                La hash n'est pas là-dessus.

                • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                  Posté par . Évalué à 2 (+2/-1).

                  La hash n'est pas là-dessus.

                  Pourquoi pas ?

                  C'est toi qui réduit le système à un simple code à 3 chiffres. Mais ce n'est pas réellement un code à trois chiffres. C'est un code partagé: l'utilisateur entre 3 chiffres ET la machine entre aussi 3 chiffres (que tu ne connais pas: tu vois les chiffres à l'écran, mais tu n'as aucune idée de comment ils sont traités).

                  Le "protocole" que j'ai proposé fonctionne: je peux bel et bien créer un système qui fonctionne comme décrit. Et celui-ci ne permet effectivement pas de décoder aussi simplement que tu le prétends.

                  Tu nous dis que un système où l'utilisateur entre 3 chiffres basés sur des questions du type "entrez les chiffres aux positions X, Y et Z" est équivalent à un système où l'utilisateur a un mot de passe à 3 chiffres.
                  Je t'ai proposé un proof-of-concept où ce n'est pas le cas.
                  C'est donc un contre-exemple valide.
                  Par contre, je suis d'accord avec: "un système où l'utilisateur entre 3 chiffres basés sur des questions du type "entrez les chiffres aux positions X, Y et Z" et qui a un protocole assez stupide est équivalent à un système où l'utilisateur a un mot de passe à 3 chiffres"

                  PS:
                  Autre exemple de protocole qui fait échouer ton approche:
                  - si la question est la combinaison 1, les "fils du pavé tactile" sont permutés: lorsqu'il rentre 1, c'est comme s'il rentrait 2, lorsqu'il rentre 2, c'est comme s'il rentrait 3, …
                  - si la question est la combinaison 2, les "fils du pavé tactile" sont permutés: lorsqu'il rentre 1, c'est comme s'il rentrait 0, lorsqu'il rentre 2, c'est comme s'il rentrait 9, …
                  - …
                  et ces permutations sont internes, gérée par le protocole.
                  Dans ce cas, tu verras plutôt:
                  x9x8x3
                  21x25x
                  xx21x4
                  Et tu ne pourras rien en conclure.

        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par . Évalué à 5 (+4/-1).

          Ça me parait trop bancal pour être ça. De toutes manières, il n'y a pas assez d'entropie sur un mdp de 6 chiffres pour résister à une attaque bruteforce, donc à mon avis ça n'est pas du tout comme ça que ça fonctionne. Tous ces systèmes reposent sur une sécurité par blocage après un nombre très limité de tentatives ; le mot de passe n'est là que pour rendre improbable de rentrer dans le système en "devinant" le mot de passe, même si on le connait partiellement (un ou deux chiffres entr'aperçus).

          Si on oublie le problème d'interception du mdp lors de sa réinitialisation, qui doit évidemment arriver de temps en temps du fait des blocages sensibles, le défaut du système est qu'il devient possible de voir une personne taper son mot de passe, qui est court et très simple. Par exemple, si on voit 3 chiffres du les 4 d'un code de carte bancaire, il devient tout à fait possible de tenter de deviner le dernier avec trois tentatives. Créer un mdp "tournant" (un seul mdp à retenir mais seulement une sous-partie demandée à chaque fois) protège cette partie, car c'est comme si on avait 20 mots de passe différents (mais on a l'impression de n'en retenir qu'un). C'est plutôt ingénieux, non?

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par (page perso) . Évalué à 1 (+0/-1).

            Ce n'est pas, il me semble, le sujet auquel je répondais.

            • étape 1 : donner son compte client, et sa date de naissance
            • étape 2 : donner 3 chiffres, sur les 6 que composent son code secret. Les 3 chiffres à donner variant à chaque nouvelle connexion, ie le système demande par exemple les chiffres en position (1,4,6) puis la fois suivante (2,3,5) etc… via un clavier virtuel.

            Tu peux stocker 20 hashes de 3 chiffres (un par combinaison), je ne suis pas certain du tout que ça facilite une attaque éventuelle…

            Oui, cela affaiblit et donc, facilite. Cela indépendamment :

            • de la taille du mot de passe (un mot plus long est aussi pourri si on demande que 3) ;
            • du nombre de tentative (il y a possibilité de vol de la DB, le hashing est surtout utilisé contre cela) ;
            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par . Évalué à 3 (+1/-0).

              Oui, cela affaiblit et donc, facilite.

              Je ne comprends pas. J'ai l'impression que tu imagines que l'attaquant a accès à la DB de la banque. Est-ce que c'est un scénario plausible? Je n'ai jamais entendu parler d'une telle situation, et pourtant, les DB des banques doivent être parmi les cibles les plus convoitées. Peut-être sont-elles hors de portées, ou bien sont-elles suffisamment protégées pour qu'une quelconque intrusion soit immédiatement détectée? En tout cas, elles seraient attaquable même avec des mdp de 6 chiffres, dont le raisonnement ne tient pas : la sécurité recherchée n'est pas du tout ciblée sur les hash et la DB.

              Je pense que la procédure dont on parle ne sert qu'à une seule chose : sécuriser l'accès au compte dans le cadre de la règle de blocage après trois erreurs. Quelle est la plus grosse faille dans ce cas? Bien sûr, le couteau sous la gorge. Mais après? Qu'on intercepte ton code, que ce soit en regardant par dessus ton épaule, ou en te refilant un PC daubé, voire en interceptant la connexion (MitM ou autres). Du coup, ne jamais réutiliser le même mdp pourrait être une solution. Sauf que ça n'est pas pratique du tout, personne ne voudrait apprendre 20 mots de passe. La solution de te demander un mdp partiel a donc une certaine élégance, puisqu'au prix d'une diminution de l'entropie du mdp (dont tu te fiches à cause de la règle des trois essais), tu as 20 mots de passe pour le prix d'un. Tu peux même en avoir beaucoup plus si tu autorises les combinaisons non-ordonnées, d'ailleurs (style : le 6e, le 2e, et le 5e chiffre). Bref, tu as virtuellement un mdp unique pour chaque connexion, même si l'utilisateur se fait piquer son mdp, tu ne pourras pas te reconnecter. Le seul code à garder secret est le mdp à 6 chiffres, mdp que personne ne te demandra jamais. Tu pourrais juste le reconstituer après plusieurs (au moins 4 ou 5) interceptions à la fois du mdp et de la séquence demandée. Je trouve que c'est une solution plutôt élégante pour générer des mdp uniques, non?

        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par . Évalué à 1 (+0/-0).

          C'est vrai, mais en cas de fuite de la DB, même avec un seul hash, 10⁶ combinaison à tester c'est trivial à péter (même avec bcrypt ou pbkdf2).

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par . Évalué à 1 (+0/-0).

            Je pense que beaucoup de gens ici ne font que transposer les techniques "de pages web" au cas des banques, mais je doute très fort que ce soit le cas.
            Dans le cas des pages web, si je rentre le texte "blabla", c'est le texte "blabla qui est envoyé et donc passé dans le hash.
            Pour une banque, un terminal dédié n'a aucune raison de transformer les touches numériques en lettre, et entrer "123456" ne signifie pas que c'est le texte "123456" qui est passé dans le hash.
            Par exemple, "1" peut très bien être traduit par le code binaire 01110101, et "2" par 11001100 et … Du coup, si tu as la DB, ce n'est pas suffisant, car tu n'as pas le "dictionnaire" qui te permet de savoir quel "mot" correspond à "1", …

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par . Évalué à 1 (+1/-1).

              Ce que tu décris ça ressemble à une technique de page web avec une super couche de sécurité par l'obscurité faite maison :p

              J'arriverais jamais à faire confiance dans le sens responsabilité des banquiers comme ça, sur parole, voir pire sur « oh quand même, ça serait trop grave s'ils faisaient n'importe quoi ».

              • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                Posté par . Évalué à 1 (+0/-0).

                Ce dont je parle n'est pas "une couche par l'obscurité faite maison pour augmenter la sécurité à l'arrache".
                Mais il n'est pas question ici de "rajouter" quelque chose pour rendre légèrement plus difficile le déchiffrage. Effectivement, si c'est le cas, c'est inquiétant et même ridicule.

                Ce que je dis, c'est que simplement, il n'y a aucune raison que la banque transforme leur données pour qu'elles soient compatibles ascii juste sans aucune raison valable, et par conséquent le problème est différent (car d'un côté, c'est: "trouver le hash à partir du mot qui est celui qui a été donné", et de l'autre, c'est "trouver le hash ET le mot à partir des infos donnés à la banque").

                C'est l'élément que je souhaitais pointer (peut-être que je me suis mal exprimé): les DB de mots de passe de pages web ont des contraintes que celles des banques n'ont par construction pas (par exemple le besoin de communiquer avec un logiciel client créé par une autre compagnie basée sur des standards de communications, comme ça l'est pour le navigateur).

    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

      Posté par . Évalué à 6 (+7/-2). Dernière modification le 20/03/17 à 13:15.

      À mon avis, elle stocke le mot de passe en clair…
      Je suis effaré du nombre de sites qui t'envoient encore ton mot de passe en clair par mail quand tu t'inscris en 2017. !

      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

        Posté par . Évalué à 2 (+2/-2).

        On parle de banque la , pas du site de shopping de tata ginette , c'est réglementé , normalisé et subissent regulièrement des audits.

        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par (page perso) . Évalué à 2 (+2/-2).

          On parle de banque la , pas du site de shopping de tata ginette , c'est réglementé , normalisé et subissent regulièrement des audits.

          Je rêve ou je viens de lire "on parle de banques, ils sont au top sur la sécurité informatique" ?

          Tu n'as visiblement jamais approché le moindre bout d'informatique bancaire à moins de 100 kilomètres.

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par . Évalué à 2 (+4/-3).

            Tu n'as visiblment jamais approché de près ou de loin le logiciel et l'infra d'un site d'e-banking.

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par (page perso) . Évalué à 4 (+5/-3).

              C'est la même merde, développée à l'arrache par des stagiaires/juniors SSII vendus comme experts web, en J2EE 1.4 ou PHP, avec la partie mainframe COBOL en moins par rapport aux banques traditionnelles sous-traitée à la DSI de la maison-mère qui est une banque tradi/à la banque tradi actionnaire.

              Mais le front est en CSS3/responsive !

              Merci, mais non merci.

              • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                Posté par . Évalué à 7 (+6/-0).

                Euh non. Excuse-moi de te contredire mais c'est mon métier, donc je sias de quoi je te parle.

                Il y a des normes très précises sur les exigences de sécurité. Après une banque peut faire le choix de pas les implémenter complètement (il y a en réalité plein de trucs comme ça où ça finit par un "risk acceptance" signé par les départements légal/compliance/risk, et pas seulement pour le site web), mais en cas d'incident majeur, ça peut piquer beaucoup beaucoup.

                Autant l'intranet peut être un peu léger sur la sécu, autant en général on ne rigole pas avec la partie e-banking. Tout dans ce domaine est classifié high-risk, avec des exigences particulières (scanning statique de code, analyse dynamique type Burp & Co, Penetration Test effectuée par des consultants sécialisés, sans compter les firewalls applicatifs, les DMZ spécifiques, les HSM et tout le tralala kivanbien).
                Aors comparer ça avec une page perso free écrite par ton cousin de 8 ans, non, désolé.

                • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                  Posté par . Évalué à -3 (+0/-5).

                  j'aime bien le : > tralala kivanbien

                  c'est sous excel 2008, c'est ca ? car la société général et mr kerviel sont en bizbiz suite a une deprotection des limites de la feuille excel envoyé par mail.

                  société général prénom de mon petit cousin de 8 ans

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par . Évalué à 5 (+3/-0).

            Je rêve ou je viens de lire "on parle de banques, ils sont au top sur la sécurité informatique" ?

            Wat… A quel moment j'ai écrit ça ?

            Tu n'as visiblement jamais approché le moindre bout d'informatique bancaire à moins de 100 kilomètres.

            Bah si tu le dis hein…

        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par (page perso) . Évalué à 2 (+2/-1).

          En vérité, les banques sont peut être le pire exemple dans le domaine de la sécurité qu'on peut prendre.

          Il faut être pragmatique sur un point, ce n'est pas rentable pour les banques d'investir dans la recherche et le développement pour sécuriser leurs infrastructures. La réalité est qu'il est plus rentable de fixer un problème de sécurité à chaud pour la banque que d'avoir des permanents qui travaillent sur ce sujet (après on peut discuter de la moralité de cette décision).

          Pour ce qui est de la sécurité, il faut plutôt ce tourner vers des systèmes militaires et aéronautiques ou encore la recherche, les considérations y sont plus fortes (rien que le facteur vie humaine est à prendre en compte).

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par . Évalué à 4 (+2/-0). Dernière modification le 21/03/17 à 09:02.

            En vérité, les banques sont peut être le pire exemple dans le domaine de la sécurité qu'on peut prendre.

            Il faut être pragmatique sur un point, ce n'est pas rentable pour les banques d'investir dans la recherche et le développement pour sécuriser leurs infrastructures. La réalité est qu'il est plus rentable de fixer un problème de sécurité à chaud pour la banque que d'avoir des permanents qui travaillent sur ce sujet (après on peut discuter de la moralité de cette décision).

            Pour ce qui est de la sécurité, il faut plutôt ce tourner vers des systèmes militaires et aéronautiques ou encore la recherche, les considérations y sont plus fortes (rien que le facteur vie humaine est à prendre en compte).

            Hmmm ça me semble péremptoire comme remarque. Ou tout du moins ça ne s'applique pas forcément partout. J'ai bossé dans le milieu bancaire en Suisse il y'a quelques années et la FINMA (Autorité fédérale de surveillance des marchés financiers) faisait des audits réguliers et rigoureux au niveau de la sécurité et ces contrôles étaient pris très sérieusement par ladite banque. Une banque ne fait pas non plus ce qu'elle veut si elle ne veut pas perdre sa licence.

            Après c'était une petite et jeune banque, pionnière du côté des services en ligne (sur 400 employés les 2/3 étaient des ingénieurs) avec aussi une petite infra qui tenait sur 2 datacenter donc relativement facile à contrôler en détail et je n'ai jamais travaillé dans une banque française donc c'est peut-être très différent suivant les pays et la taille de la boite.

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par . Évalué à 5 (+3/-0). Dernière modification le 21/03/17 à 09:07.

              J'ajouterai que j'ai eu plus tard des collègues qui avaient bossé pour des banques plus grosses comme l'UBS et le crédit Suisse et la sécurité qu'elle soit physique ou informatique n'était pas prise à la légère d'après les échanges d'expériences que l'on avait eu.

              Pendant le même laps de temps on a eu quelques scandales du côté de l'armée qui s'était fait voler des munitions par exemple. Bref…

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par (page perso) . Évalué à 1 (+0/-1).

            Dans l'aéronautique, il y a plein de process. Pas pour empêcher que l'avion se crashe, mais pour que si ça arrive, on sache de qui c'est la faute.

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par (page perso) . Évalué à 2 (+1/-1).

              C'est faux.

              Dans l'aéronautique, tu as des niveaux de criticité associé au développement de ton équipement ce qui l'on appelle des Development Assurance Level.
              Ces niveaux de criticité se basent sur la fréquence admissible d'une panne par rapport aux dégâts qu'il peut engendrer (sans effet, blesser ou tuer des gens). Ce qui est résumé par Wikipédia concernant la norme en question.

              En gros, plus ton développement est jugé risqué (par exemple tout ce qui est contrôle des moteurs ou du pilotage de l'avion), plus tu devras non seulement produire des documents complets concernant l'architecture de ton produit (qui sera audité par des organismes de contrôles et peuvent refuser de certifier ton produit en cas d'erreurs manifestes) mais aussi apporter des preuves ou de la redondance dans le composant.

              Ce n'est pas pour rien que beaucoup d'équipement critiques d'un avion ne peuvent pas exploiter encore un microprocesseur moderne, car leur comportement n'est pas certifiable. C'est pour cela aussi que pour certaines pièces il faut des équipement de secours, parfois produits par un constructeur différent, pour limiter au maximum les risques.

              Bref, la certification aéronautique ne peut pas garantir le risque 0 de défaillance technique. Mais dans l'ensemble, c'est plutôt efficace pour réduire les risques au maximum (et non juste taper sur le coupable, bien que cette méthodologie autorise cela aussi).

      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

        Posté par . Évalué à 3 (+0/-0). Dernière modification le 21/03/17 à 00:57.

        Ou dans un HSM. Le HSM peut faire en sorte que la donnée ne sort jamais nul part et empêcher le brut force.

        Bref on sait pas trop quoi…

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

      Posté par . Évalué à 3 (+2/-0).

      Je ne vois pas trop ce que ça change : 6 chiffres ça ne fait que 100.000 possibilités. Donc de toutes façons une attaque par force brute semble possible, non ?

      Et si tu stockes le sel à côté dans la base ça ne rend pas l'opération plus complexe. Il faudrait qu'il soit stocké avec l'appli, donc le même pour tout le monde.

      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

        Posté par (page perso) . Évalué à 2 (+1/-1).

        Donc de toutes façons une attaque par force brute semble possible, non ?

        Au bout de 3 codes faux, ça bloque l'accès au compte.

        It's a fez. I wear a fez now. Fezes are cool !

        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par (page perso) . Évalué à 5 (+4/-1). Dernière modification le 20/03/17 à 16:49.

          Ouf, on est sauf.

          • On a jamais vu de DOS sur le web… Trouver num. de compte + date de naissance, c'est totalement impossible.
          • On a jamais vu de vol de DB.
        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

          Posté par . Évalué à 3 (+2/-0).

          Au bout de 3 codes faux, ça bloque l'accès au compte.

          C'est pas facile de compter jusqu'à trois… Trois tentative depuis la même IP ?

          Comme l'argent c'est le même sur tous les comptes, le plus gros danger c'est pas celui qui disposant de moyens limités veut se connecter à un compte en particulier, c'est celui ayant des gros moyens à sa disposition souhaitant se connecter sur un maximum de comptes.

          En supposant que l'attaquant connaisse les numéros des clients :
          Les dates de naissances pour les gens ayant entre 68 ans et 18 ans il y en a en gros 20000, pas du tout uniforme, ça apporte peu de sécurité, le mot de passe à 3 chiffre, c'est une blague. Même en tapant au hasard ça fait une connexion réussie sur 20 000 000, c'est pas rien. Et en prenant en compte la structure des dates de naissance des clients, il doit y avoir moyen de faire bien mieux.

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par . Évalué à 7 (+5/-0).

            C'est pas facile de compter jusqu'à trois… Trois tentative depuis la même IP ?

            Non, c'est 3 tentatives tout court. Ça me semble super-facile.

            Même en tapant au hasard ça fait une connexion réussie sur 20 000 000, c'est pas rien.

            C'est beaucoup plus que le nombre de clients de la plupart des banques :-) Ça limite quand même énormément les risques d'intrusion. Pense que l'objectif n'est pas forcément d'avoir une sécurité à 100%, c'est de faire en sorte que les risques soient gérable. Si tu as 100 millions de comptes et qu'en moyenne tu as 2000€ par compte, un attaquant qui te pique ta DB de numéros de clients va pouvoir te pomper… 10000€, que tu vas pouvoir très facilement recréditer à tes clients. Pour une attaque majeure, qui n'arrive probablement que très rarement, et que tu vas assez facilement pouvoir bloquer si tu as des systèmes de monitoring performants (du style, repérer un pic de blocages après tentatives infructueuses).

            il doit y avoir moyen de faire bien mieux.

            Reconvertis-toi dans le piratage des banques :-) Il faudrait regarder l'évolution de la fraude, ça augmente régulièrement mais je ne sais pas trop quels sont les facteurs principaux. Je doute que le piratage de l'accès électronique aux comptes bancaires soit la cause majeure, c'est beaucoup trop facile à bloquer (en particulier, il n'y a que dans les films où les virements sont instantanés, en général il faut au moins 24h pendant lesquelles le virement peut être annulé par la banque).

            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

              Posté par . Évalué à 3 (+2/-0).

              Non, c'est 3 tentatives tout court. Ça me semble super-facile.

              Ça semble du coup super facile de faire du déni de service… Tu me donne ton numéro de client et ta date de naissance ? C'est pour une expérience :-p

              Après, moi… Si j'avais envie de me lancer dans ce business (j'aime pas assez l'argent et trop ma liberté d'aller et venir pour le faire), je ne viderait pas un compte, je me contenterait d'un petit prélèvement innocent de 22,54€ de temps en temps…

              • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                Posté par . Évalué à 2 (+1/-1).

                Ça semble du coup super facile de faire du déni de service… Tu me donne ton numéro de client et ta date de naissance ?

                Ouais, du coup ça semble super-dur de faire du déni de service, parce qu'il faut une DB de numéros de clients et de dates de naissances. On peut pourrir mille personne mille fois… non, on peut pourrir une fois une personne… euh non, mille fois mille personnes…

                Par contre, c'est vrai du coup qu'on peut pourrir mille fois une personne, puisqu'à moins de changer le numéro de client, une personne malveillante peut te bloquer ton compte toutes les semaines. Je pense que dans ce cas tu changes de numéro de client, le mien reprend le pattern du numéro de compte mais il y a plusieurs chiffres aléatoires dedans. Mais bon, c'est du DDOS bas débit :-)

              • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                Posté par (page perso) . Évalué à 1 (+3/-4).

                Tu me donne ton numéro de client et ta date de naissance ?

                Donc tu ne les connais pas. CQFD.
                (en pratique, la difficulté est de choper ces données, et encore elle ne servent qu'à mater ton compte en banque, pas à virer de l'argent car il faut alors le code par SMS)

                prélèvement

                Pas compris le rapport, vu que pour prélever il faut un IBAN, et que ce n'est pas tout le monde (et surtout pas un particulier) qui peut prélever.


                Ce qu'oublient pas mal d' "experts en sécurité amateurs de LinuxFr", c'est que la sécurité vaut ZERO si elle est trop compliquée par rapport au besoin (zéro car pas d'utilisateur donc pas de revenu), et les banques ont pour le moment trouvé justement la balance entre complexité et utilisabilité.
                Libre à vous de proposer "mieux", mais promis je ne viendrai pas chez vous car ça sera trop chiant de se connecter (et je n'aurai pas une meilleur sécurité en pratique, celle de ma banque me convenant car a démontré son efficacité avec peu de sous disparus pour le volume de transactions)

                La sécurité ne vaut que si elle est adaptée au risque, tout le monde n'a pas besoin d'avoir la même protection que le président des USA.

                • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                  Posté par . Évalué à 3 (+3/-1). Dernière modification le 21/03/17 à 01:16.

                  Donc tu ne les connais pas. CQFD.
                  (en pratique, la difficulté est de choper ces données, et encore elle ne servent qu'à mater ton compte en banque, pas à virer de l'argent car il faut alors le code par SMS)

                  Si j'étais proche de lui je les connaîtrais…

                  Pas compris le rapport, vu que pour prélever il faut un IBAN, et que ce n'est pas tout le monde (et surtout pas un particulier) qui peut prélever.

                  Virement rhoooooo, t'es de mauvais poil ?

                  Ce qu'oublient pas mal d' "experts en sécurité amateurs de LinuxFr", c'est que la sécurité vaut ZERO si elle est trop compliquée par rapport au besoin (zéro car pas d'utilisateur donc pas de revenu), et les banques ont pour le moment trouvé justement la balance entre complexité et utilisabilité.

                  Les gens ne choisissent pas leur banque en fonction de la facilité d'utiliser tel ou tel service. En fait, ils s'adaptent.
                  Après, faut pas se foutre de la gueule du monde… Pour les géants du web la double authentification est presque la norme, et ton utilisateur typique trop débile pour retenir un mot de passe plus compliqué que 6 chiffre s'en sort très bien avec…

                  La sécurité ne vaut que si elle est adaptée au risque, tout le monde n'a pas besoin d'avoir la même protection que le président des USA.

                  Tout à fait, et c'est précisément pour ça qu'absolument rien ne justifie que l'authentification sur le site d'une banque soit plus faible que celle effectuée sur un réseau social ou un hébergeur mail.

                  • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                    Posté par (page perso) . Évalué à 1 (+2/-3). Dernière modification le 21/03/17 à 09:59.

                    Si j'étais proche de lui je les connaîtrais…

                    La seule personne (à part la banque, mais sérieux on va parler de l’informaticien de la banque qui voudrait chier?) qui connaisse où trouver mon numéro client est celle avec qui je dors, donc bon je saurai assez vite qui m'emmerde.
                    Si tu files ton numéro client à plus de monde, le problème est entre l'interface chaise-clavier.

                    Tout à fait, et c'est précisément pour ça qu'absolument rien ne justifie que l'authentification sur le site d'une banque soit plus faible que celle effectuée sur un réseau social ou un hébergeur mail.

                    je ne connais pas de "réseau social ou un hébergeur mail." en lecteur seule, tu peux me donner une exemple?
                    Parce qu'ensuite, quand il faut faire un virement (l'équivalent d'écrire), je ne connais aucune banque qui n'impose pas la double authentification, alors que dans tes exemples c'est optionnel.

                    Donc, bon, ben voila quoi. CQFD, encore une fois.

                    Ce qui vous manque dans vos démos, c'est votre démonstration que la sécurité n'est pas suffisante, bizarrement vous n'en parlez pas…

                    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                      Posté par . Évalué à 3 (+1/-0).

                      Dans au moins une grosse banque française, ton identifiant c'est ton numéro de compte.
                      Donc tous les clients de cette banque qui ont un jour donné leur RIB à qqun pour un virement sont susceptibles de se faire bloquer leur compte par un "pote"/client/…

                      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                        Posté par (page perso) . Évalué à 1 (+1/-2).

                        Il y a des cons partout, mais la je n'en tient pas compte :).
                        (quitter cette banque le plus rapidement possible…)

                      • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                        Posté par . Évalué à 2 (+0/-0).

                        Dans au moins une grosse banque française, ton identifiant c'est ton numéro de compte.

                        C'est bizarre, tu es sûr? Un client peut avoir plusieurs numéros de compte, et un compte peut correspondre à plusieurs personnes physiques (compte joint). Chez moi, le login reprend le pattern du premier compte que j'ai créé dans cette banque, mais ensuite il y a plusieurs chiffres supplémentaires "aléatoires".

                        De toutes manières, "un grosse banque française" c'est pas assez précis pour qu'on puisse vérifier, hein…

                        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                          Posté par (page perso) . Évalué à 4 (+2/-0).

                          Oui oui, au crédit agricole on se connecte avec un des numéros de comptes (n'importe lequel, si tu en as plusieurs) et un mot de passe à 6 chiffres (le même pour tous les comptes pour 1 personne). Il faut juste espérer que 2 personnes ayant accès au même compte ne choisissent pas le même code secret, sinon, je sais pas ce qu'il se passe. Surtout que ça marche aussi si tu as accès à des comptes qui n'ont rien à voir entre eux (genre, mon compte personnel et celui d'une association dont je suis trésorier).

                          Et oui, il est très facile de rentrer 3 mauvais codes et de bloquer l'accès de quelqu'un. Mais il est tout aussi facile d'envoyer un mail à son banquier pour lui expliquer que le compte est bloqué et lui demander de réinitialiser et de renvoyer le code à 6 chiffres, le tout par mail (testé, ça fonctionne).

                          Bien sûr, pas possible d'utiliser la messagerie sécurisée prévue à cet effet, puisqu'elle est protégée par le même moyen que le reste. Du coup cela se fait avec une adresse mail normale et pas sécurisée.

                          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                            Posté par . Évalué à 2 (+0/-0).

                            n'importe lequel, si tu en as plusieurs

                            Du coup, ça veut dire que la méthode d'identification n'est pas du tout traditionnelle, non? Chaque utilisateur a plusieurs id (ses différents comptes) et un seul mdp. Du coup, ils doivent garder un hash par couple (id,mdp) et retrouver l'utilisateur à partir de ça. Mais du coup comment font-ils pour savoir à qui renvoyer le mdp quand un compte joint est bloqué? Aux deux, j'imagine?

                            Du coup cela se fait avec une adresse mail normale et pas sécurisée.

                            J'imagine quand même qu'il faut changer le mdp à la première utilisation, autrement c'est portnawak…

                            • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                              Posté par (page perso) . Évalué à 2 (+0/-0).

                              Du coup, ils doivent garder un hash par couple (id,mdp) et retrouver l'utilisateur à partir de ça. Mais du coup comment font-ils pour savoir à qui renvoyer le mdp quand un compte joint est bloqué? Aux deux, j'imagine?

                              Oui, a priori tous les mots de passes associé au compte sont bloqués (puisqu'on ne peut pas savoir lequel de ces mots de passe était le "bon" pour la personne essayant de s'identifier avec 3 mauvais mots de passe).

                              Et oui, une fois l'accès débloqué il faut changer le mot de passe. Mais on peut remettre l'ancien sans que ça pose problème à leur appli, il me semble…

                        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                          Posté par (page perso) . Évalué à 2 (+1/-0).

                          De toutes manières, "un grosse banque française" c'est pas assez précis pour qu'on puisse vérifier, hein…

                          Crédit Agricole.

                        • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

                          Posté par . Évalué à 4 (+2/-0). Dernière modification le 22/03/17 à 17:56.

                          J'en suis sûr parce que c'est ma banque … Crédit Agricole pour ne pas la citer. J'ai eu peur de l'effet Linkeo alors j'ai préféré taire le nom mais ça a été confirmé plus haut.
                          [EDIT]
                          Et le plus chiant c'est qu'on t'y oblige à lier tes différents comptes, donc le compte de ma boîte (SASU donc personne morale distincte de moi !) passe par la même identification avec mon n° de compte perso ! C'est aberrant mais je suis fautif, à l'époque j'ai eu la flemme de courir les banques pour chercher une alternative, sachant que je suis chez eux depuis 20 ans …

          • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

            Posté par . Évalué à 1 (+0/-0). Dernière modification le 21/03/17 à 00:02.

            ça fait une connexion réussie sur 20 000 000

            Et tu imagines que tu vas pas faire couiner un IDS ou une autre sonde du genre avant ?

    • [^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun

      Posté par (page perso) . Évalué à 4 (+3/-1).

      Ton analyse à plusieurs faiblesses. La plus grave est que tu ne fais pas tout l'analyse des menaces sur l'utilisateur de la banque en ligne et ne peut donc pas critiquer la solution que tu prétends analyser au regard de son efficacité. Le second point est que ton discours, purement technique, entame rapidement ta crédibilité: il n'y a aucun intérêt à hasher des chiffres: il n'y a que dix chiffres et donc autant dix valeurs de hashs possibles.

      L'intérêt du procédé est qu'il demande à l'utilisateur de montrer qu'il connaît un secret, sans dévoiler l'intégralité du secret à la connexion. Il y a de nombreuses situations où cela se montre utile, par exemple si on se connecte en public (sur son portable) ou si l'ordinateur est surveillé informatiquement (par exemple via une vulnérabilité du navigateur).

      (Ceci dit il faut rappeler que cette procédure de connexion permet d'accéder aux relevés bancaires mais ne permet de réaliser aucune transaction, pour lesquelles une authentification supplémentaire est nécessaire.)

  • # 2FA

    Posté par (page perso) . Évalué à 5 (+4/-0). Dernière modification le 20/03/17 à 13:38.

    pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

    Le Crédit Coopératif, en tout cas pour les clients pro, fournit une carte à puce et un lecteur de carte délivrant un OTP nécessaire à chaque connexion et pour les opérations sensibles.

    • [^] # Re: 2FA

      Posté par . Évalué à 4 (+2/-0).

      en tout cas pour les clients pro

      C'est également le cas pour les particuliers, et depuis un bout de temps.

      • [^] # Re: 2FA

        Posté par . Évalué à 3 (+1/-0).

        Et ce n'est pas obligatoire : par défaut, on a ce système, mais on peut se créer un mot de passe pour pas être emmerdé avec la carte à chaque connexion.

        • [^] # Re: 2FA et coup de gueule

          Posté par (page perso) . Évalué à 1 (+0/-0).

          Pour effectuer un virement ou créer un nouveau bénéficiaire c'est obligatoire, fini le mot de passe partout, mais surtout pour payer sur tous les sites 3D Secure.

          Mais je ne prendrais pas cet exemple… Parce que en pratique c'est super super contraignant.
          Pas de paiement en ligne ou téléphone si on a pas sa CB et son petit boitier pour obtenir son "secure code".

          Prendre un billet de train SNCF depuis l'étranger quand on est en vadrouille : fini.
          Payer sur un site 3D secure chez un pote pour le dépanner ou depuis un cybercafé : fini.
          Déclencher un nouveau virement depuis son mobile pas de chez soi : fini.
          Etc…

          Le pire dans tout ça c'est que le Crédit coopératif expliquait dans sa FAQ que ce sont ses clients qui ont dit "préférer" ce mode de paiement alors que c'est totalement FAUX. Les questions ont été posées en AG, les clients n'ont pas été consultés directement là-dessus. Un joli code de confirmation sur son téléphone comme tout le monde ça aurait probablement suffit.

          Ici on a un système :
          - Qui nécessite l'envoi et la gestion des calculettes : bonjour le coût !
          - Qui est une hérésie pour la planète : il faudra bien remplacer ces calculettes (ma pile commence à faiblir). QUid de la compromission de la méthode de génération du code à 8 chiffres ?
          - Qui fait perdre du temps à chaque fois (trouver la calculette, trouver la CB, faire son code PIN, entrer sur le site le code à 8 chiffres).
          - Qui est moins pratique et contraignant car restreignant les cas d'utilisation client

          In fine, c'est la banque qui est protégée, mais pas l'utilisateur final. C'est très simple la sécurité, il suffit de reporter la contrainte sur le client final…

          • [^] # Re: 2FA et coup de gueule

            Posté par . Évalué à 2 (+1/-0).

            • Qui nécessite l'envoi et la gestion des calculettes : bonjour le coût !

            Un petit appareil électronique qui dure des années… Ça va…

            • Qui est une hérésie pour la planète : il faudra bien remplacer ces calculettes (ma pile commence à faiblir).

            J'ai changé la mienne pour la première fois au bout de 6 ou 7 ans… Ça va… (Quand elle dit qu'elle commence à faiblir tu en as encore pour des années).

            QUid de la compromission de la méthode de génération du code à 8 chiffres ?

            C'est une bonne question. Je suis curieux de la réponse aussi

            • Qui fait perdre du temps à chaque fois (trouver la calculette, trouver la CB, faire son code PIN, entrer sur le site le code à 8 chiffres).

            Et le temps c'est de l'argent ? Oui, ça prend du temps, exactement de la même manière que taper un mot de passe à 10 chiffres prend plus de temps que cliquer sur le bouton « Meuh si c'est moa ». Et si c'est juste pour te loguer, tu peux mettre un mot de passe.

            • Qui est moins pratique et contraignant car restreignant les cas d'utilisation client

            C'est normal que ce soit moins pratique et contraignant, c'est fait pour être plus sûr. Et oui, il y a quelques cas où c'est contraignant, c'est parfois impossible de payer sans le boitier.

            In fine, c'est la banque qui est protégée, mais pas l'utilisateur final. C'est très simple la sécurité, il suffit de reporter la contrainte sur le client final…

            Qu'est-ce que tu veux dire ? La banque ne peut pas déporter toute la sécurité chez elle, c'est juste impossible, vu que l'enjeu est justement d'assurer l'authentification du client.

            • [^] # Re: 2FA et coup de gueule

              Posté par (page perso) . Évalué à 2 (+0/-0).

              Ah ben bravo pour la planète: la pile faiblit, je change tout le boîtier!

              Sur le modèle dont je dispose la pile est accessible (petite vis et cache en plastique à l'arrière) et remplaçable facilement.

              Et donc oui, il faut avoir le boîtier sur soi ou en trouver un là ou on est, ce qui ne pose pas problème si le boîtier en question est standardisé (apparament c'est le cas en belgique).

              Parce que payer avec un téléphone portable depuis l'étranger, ça suppose d'avoir le forfait qui va bien, et c'est pas non plus le cas de tout le monde (pour ceux qui ont un téléphone, déjà, hein).

  • # mdp un peu plus sécurisé.

    Posté par . Évalué à 6 (+5/-0).

    Je ne sais pas si c'est partout en Belgique, mais pour ma part, j'ai un boitier qui accepte une carte de banque, n'importe quelle carte (je pense que si j'utilise le boitier d'une autre banque, cela devrait aussi fonctionner).

    Lors de ma connection à la banque, on me demande sur quel compte je veux entrer. Ensuite, il m'est envoyé un code valable un cours laps de temps. Code en 8 ou 6 chiffres. Je dois placer ma carte dans mon boitier, non raccordé au ouaib, entrer mon code (je suppose que malgré tout, le code doit se trouver lisible quelque part dans la carte) et entrer les chiffres que la banque me fournit. Une fois validé, une suite de chiffre est affichée sur l'écran du boitier. J'entre ces numéros dans la case ad-hoc de l'internet. Si validé, connection sur mon compte. Donc, je suppose que mon code secret est haché grâce au numéro donné. De son côté, le site d’authentification fait pareil. Il y a ensuite simple comparaison. Le tout est en https au minimum (je vois pas autre chose). Le code de "hash" est valable juste un temps, lors d'une nouvelle connection, paf le chien, on change de code à entrer.

    Il me semble que cette méthode, bien qu'imparfaite, est bien plus sûre que ce qui est donné.

    Non?

    • [^] # Re: mdp un peu plus sécurisé.

      Posté par . Évalué à 6 (+4/-0).

      Il me semble que cette méthode, bien qu'imparfaite, est bien plus sûre que ce qui est donné.

      Oui, c'est nettement plus sécurisé.

      Pour info, jusqu'à il y a quelques années, la plupart des grosses banques belges avaient le même standard.. sauf ING. Ils avaient toutefois un système similaire. Je pense qu'ils sont maintenant compatible avec les autres banques, mais à confirmer.

      De ce que j'ai pu comprendre, la carte contient une clé cryptographique qui permet de hasher des données qu'on entre manuellement dans le lecteur de carte. Ca peut être un token donné par le site web de la banque qu'on chiffre pour certifier qu'on est bien celui qu'on prétend être, ou les informations d'une transaction bancaire (montant, destinataire) pour être sur qu'à la confirmation que celles confirmées par l'utilisateur n'ont pas été altérées avant d'être transmises.

      Je sais que pour l'authentification, la date et/ou l'heure entre en ligne de compte, ce qui évite la réutilisation.

      J'avoue que j'ai du mal à comprendre comment ce système ne se généralise pas.

    • [^] # Re: mdp un peu plus sécurisé.

      Posté par . Évalué à 5 (+4/-0).

      Je vais faire double emploi avec la réponse déjà donnée, mais oui, ce n'est pas une méthode imparfaite, c'est la méthode la plus parfaite qui existe à l'heure actuelle.

      En effet, cela utilise du matériel que la banque a fourni, avec un secret que toi seul connaît, en utilisant les méthodes cryptographiques les plus sécurisées offertes aux utilisateurs. Oui parce que bon, si on arrive à casser le PIN de la carte, on peut faire autre chose que d'utiliser le site web de l'utilisateur…

      Mais d'après plein de gens (hormis les Belges qui sont habitués au système), c'est « trop contraignant ». Personnellement, je trouve le système actuel à base de clavier virtuel vraiment horrible, mais bon, pour convaincre les banques…

      • [^] # Re: mdp un peu plus sécurisé.

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Il y a la banque populaire qui propose ce système en France (en option, par défaut c'est une authentification par SMS il me semble).
        L'accès au site web se fait via un mot de passe (à taper sur un clavier normal, pas un truc virtuel débile). Ensuite on a besoin du boîtier uniquement pour valider certaines opérations du genre ajouter un bénéficiaire de virement, ainsi que pour les paiements par 3D Secure.

      • [^] # Re: mdp un peu plus sécurisé.

        Posté par . Évalué à 3 (+0/-0).

        moui. Le système le plus populaire était le système de RSA qui utilisait une clef privé connu de la NSA… Niveau sécurité zéro donc, car même clef pour tout le monde.

        "La première sécurité est la liberté"

  • # Manque d’intérêt

    Posté par (page perso) . Évalué à 4 (+3/-1).

    pourquoi les banques n'autorisent elles pas les mot de passe avec une suite de caractères (chiffres, lettres, symboles) ?
    pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

    Je me suis déjà posé les mêmes questions. Ma théorie est que pour les banques (à l’exception peut-être des banques exclusivement en ligne), les données personnelles des utilisateurs ne sont pas des données particulièrement importantes de leur point de vue (pour l’utilisateur, c’est autre chose, bien sûr). Elles n’en ont probablement pas besoin pour gagner de l’argent — une banque qui veut se faire de l’argent sur mon dos, elle va le faire en me prélevant des frais de gestion de compte, pas en exploitant mes données. Du coup, pourquoi se casser la tête à protéger quelque chose auquel on n’accorde pas une grande valeur ?

    À l’inverse, pour la plupart des « sites sérieux » qui proposent l’authentification à deux facteurs (Facebook, Google, etc.), les données personnelles des utilisateurs représentent leur fond de commerce. Ils ont tout intérêt à ce qu’elles soient bien protégées. Et donc ils font ça sérieusement.

    « Eric Schmidt does want your data to be secure. He wants Google to be the safest place for your data as long as you don’t mind the fact that Google has access to your data. Facebook wants the same thing: to protect your data from everyone from Facebook. »

    Bruce Schneier

  • # Certaines le font

    Posté par . Évalué à 3 (+2/-0). Dernière modification le 20/03/17 à 18:27.

    pourquoi les banques n'autorisent elles pas les mot de passe avec une suite de caractères (chiffres, lettres, symboles) ? (Je me doute que derrière ça doit avoir un impact sur les gros systèmes qui hébergent les applis métier).

    Il y a en a au moins une qui l'autorise (et qui du coup ne passe pas par un clavier virtuel) : Fortuneo.

    pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

    Toujours chez Fortuneo, l'authentification en 2 étapes (via l'envoi d'un code par sms valide 5') est quasi systématique dès lors qu'on fait autre chose que consulter son compte (et encore, même le téléchargement d'un RIB ou d'un relevé passe par ce mécanisme). Mais je pense que c'est le cas des autres banques pour toute opération sensible, comme un virement externe par exemple. Je trouve que c'est un compromis acceptable.

  • # Edgard de la Cambriole qui s'inquiète de la sécu des sites bancaires :)

    Posté par . Évalué à 4 (+3/-0).

    Ton avatar et le sujet m'ont fait sourire.
    Titre de l'image

  • # Des éléments de réponse

    Posté par (page perso) . Évalué à 3 (+2/-0).

    • Pour ce qui est des claviers virtuels, je les déteste. Ils sont chiants à utiliser et nécessitent JavaScript.
    • Pour l'utilisation uniquement de chiffres, ce n'est pas trop grave. Le compte est normalement bloqué après 3 essais. Les codes secrets des cartes bancaires (ou un moyen de les retrouver) sont stockés sur des HSM (des modules matériels spécialisés en sécurité, avec de la cryptographie et une suppression des données si ça bouge trop) (une bonne partie en production vient de Bull, avec des portes dérobées ?). J'imagine et j’espère qu'il en est de même pour les codes secrets des front-end web.
    • Google et Facebook arrivent à gérer plus d'un milliard d'utilisateurs et utilisatrices avec des mots de passe ne contenant pas que des chiffres. Donc les banques n'ont pas de bonne excuse pour ne pas permettre des mots de passe ayant autre chose que des nombres pour les front-end web.
    • Le module matériel directement connecté au PC pose le problème de la compatibilité : gérer Windows, macOS, et potentiellement GNU/Linux. Par contre, pour la gestion des mobiles, ça risque d’être dur. De plus, il faudrait préalablement installer un pilote. C'est donc très contraignant, mais c'est indéniablement bon pour la sécurité (si le module matériel fait bien son boulot).
    • Il y a des boîtiers dans lesquels il faut insérer une carte bancaire qui donnent un code. Ça a au moins 2 inconvénients :
      • Ça coûte pour les banques, donc in fine pour les clients.
      • Forcer l'usage est contraignant. Quand on ne change pas de logement et qu'on fait des opérations qu'à la maison, ça va. Si on voyage souvent ou que l'on veut faire des opérations sur mobile, c'est tout de suite moins pratique.
    • Certaines banques font des CVX (le cryptogramme de la carte bancaire) qui change à un intervalle régulier ou en appuyant sur un bouton. Elles pourraient le demander pour se connecter (si certaines ne le font pas déjà).
    • [^] # Re: Des éléments de réponse

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Forcer l'usage est contraignant. Quand on ne change pas de logement et qu'on fait des opérations qu'à la maison, ça va. Si on voyage souvent ou que l'on veut faire des opérations sur mobile, c'est tout de suite moins pratique.

      ça demande juste d'avoir le lecteur dans ton sac de voyage c'est pas compliqué

      Au boulot quand j'ai besoin d'un lecteur de carte, il y a tjr bien un collègue qui a le sien

    • [^] # Re: Des éléments de réponse

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Les lecteurs de cartes à puce sur USB sont plutôt bien standardisés, en fait. L'API PC/SC est disponible pour Windows et Linux (macOS je sais pas). L'interface USB est standard donc un seul driver fonctionne pour tous les modèles de lecteurs.

      Mais ça règle pas la question pour les téléphones.

      Et pour le logiciel, le mieux serait que ça soit géré par le navigateur web, peut être?

  • # Mot de passe

    Posté par (page perso) . Évalué à 3 (+0/-0).

    pourquoi les banques n'autorisent elles pas les mot de passe avec une suite de caractères (chiffres, lettres, symboles) ? (Je me doute que derrière ça doit avoir un impact sur les gros systèmes qui hébergent les applis métier)

    Certaines l'autorisent, en tout cas le CIC et le Crédit Mutuel (c'est le même groupe). En revanche, cela les empêche d'imposer une saisie de chiffre à la souris (vulnérable à l'observation par dessus l'épaule et à l'interception par un démon local mais pas aux key loggers), et leur implique donc de permettre la saisie du clavier (peu vulnérable à l'observation par dessus l'épaule, mais vulnérable aux key loggers et à l'interception par un démon local).

    • [^] # Re: Mot de passe

      Posté par . Évalué à 2 (+1/-1).

      Je ne vois pas trop en quoi clavier virtuel et clavier physique diffère sur le point « observation par dessus l’épaule ».

      Quant au keyloggers, j’ai du mal à croire qu’il n’existe pas de "clickloggers" permettant de capter le code secret de la même manière…

      Par ailleurs il serait tout à fait envisageable d’avoir un clavier virtuel possédant lettres et signes ponctuation.

      • [^] # Re: Mot de passe

        Posté par (page perso) . Évalué à 5 (+2/-0).

        Je ne vois pas trop en quoi clavier virtuel et clavier physique diffère sur le point « observation par dessus l’épaule ».

        Il me semble plus facile de suivre les mouvements d'un pointeur de souris à l'écran (lents, parce que l'utilisateur doit faire un effort pour repérer la position, aléatoire, de chaque chiffre), que les frappes de touche (rapides, parce que l'utilisateur utilise sa mémoire mécanique de la position des touches).

        Quant au keyloggers, j’ai du mal à croire qu’il n’existe pas de "clickloggers" permettant de capter le code secret de la même manière…

        Le clicklogger en question enregistrera sans problème qu'on a cliqué à telle position sur l'écran, mais pour déterminer ce qu'il y avait d'affiché à cet endroit, il faut y coupler une caputre d'écran, ce qui est un poil plus contraignant qu'un simple keylogger. Rien d'infaisable, évidemment, mais c'est nettement plus chiant, et nettement moins automatique à analyser.

        Par ailleurs il serait tout à fait envisageable d’avoir un clavier virtuel possédant lettres et signes ponctuation.

        Positionnées aléatoirement aussi ? Là, tu va faire fuir tes clients, qui en auront vite marre de passer cinq minutes à saisir leur mot de passe…

        • [^] # Re: Mot de passe

          Posté par . Évalué à 5 (+4/-0).

          Positionnées aléatoirement aussi ? Là, tu va faire fuir tes clients, qui en auront vite marre de passer cinq minutes à saisir leur mot de passe…

          5 minutes c'est pour les clients valides. Pour les clients aveugles, ça se compte en heure.

          Les claviers virtuels c'est juste de la merde.

        • [^] # Re: Mot de passe

          Posté par . Évalué à 5 (+3/-0).

          Le clicklogger en question enregistrera sans problème qu'on a cliqué à telle position sur l'écran, mais pour déterminer ce qu'il y avait d'affiché à cet endroit, il faut y coupler une caputre d'écran, ce qui est un poil plus contraignant qu'un simple keylogger. Rien d'infaisable, évidemment, mais c'est nettement plus chiant, et nettement moins automatique à analyser.

          La partie "tel site a un clavier virtuel donc il faut faire des screenshot dans les fenêtres" est toute prévue dans dridex.

          • [^] # Re: Mot de passe

            Posté par . Évalué à 1 (+0/-0).

            C'est tout à fait le problème en sécurité informatique, le "seul un spécialiste peut le faire" est vite détourné par le fait qu'il y a un spécialiste qui le fait une fois, publie, et tout le monde peut le faire ensuite via un petit outil / script…

  • # 2 facteurs

    Posté par (page perso) . Évalué à 4 (+1/-0).

    pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

    Alors, déjà, l'idée d'utiliser un token, c'est d'ajouter dans l'authentification quelque chose qui est de l'ordre de la propriété physique (en plus d'un code qui relève de la connaissance). Pour info, ces tokens utilisent un algorithme pour générer un code à partir d'un secret (l'algorithme standard pour cela s'appelle TOTP), mais tant que ça ne sort pas de l'appareil en question, ça relève bien de la propriété. En revanche, dès qu'on s'amuse à utiliser ça avec un générateur de code sur téléphone par exemple, ça s'approche un peu plus de la connaissance.

    Autrement, il y a une alternative au token algorithmique, qui est la grille de codes : c'est une carte en papier, avec un tableau dont les colonnes et les lignes sont numérotées, et qui contient dans chaque case un code unique choisi de façon aléatoire. Par rapport à un token, ça ne coûte presque rien, ça n'utilise pas d'algorithme, pas de secret partagé (en fait c'est l'ensemble de la grille qui est un secret partagé), ni d'électronique d'aucune sorte, et c'est donc invulnérable aux attaques qui portent sur ces caractéristiques. Mais à moins de changer régulièrement de grille, ça peut être vulnérable à une réutilisation d'un code déjà passé qui aurait été intercepté.

    • [^] # Re: 2 facteurs

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Pour info, ces tokens utilisent un algorithme pour générer un code à partir d'un secret (l'algorithme standard pour cela s'appelle TOTP), mais tant que ça ne sort pas de l'appareil en question, ça relève bien de la propriété. En revanche, dès qu'on s'amuse à utiliser ça avec un générateur de code sur téléphone par exemple, ça s'approche un peu plus de la connaissance.

      Le principal défaut d'un OTP logiciel genre FreeOTP sur smartphone est qu'un smartphone est connecté à tous les réseaux qui existent et sont la cible d'attaques. Mis à part ce point, mot de passe + FreeOTP me semble carrément plus sûr qu'uniquement un mot de passe.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.