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 totof2000 . Évalué à 10.
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 Anonyme . Évalué à 3.
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 arnaudus . Évalué à 10.
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.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Spone Gary . Évalué à 2.
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 fcartegnie . Évalué à 9.
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 Spone Gary . Évalué à 5.
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 fcartegnie . Évalué à 2.
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 Spone Gary . Évalué à 2.
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 dyno partouzeur du centre . Évalué à 7.
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 n.rigaud . Évalué à 1.
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 Maxime Ritter (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4. Dernière modification le 22 mars 2017 à 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 :
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 Prosper . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
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 Prosper . Évalué à 3.
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 oinkoink_daotter . Évalué à 3.
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 :
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 :
J'en déduis que le consortium sait ce qu'est une authentification multifacteurs.
[^] # Re: Un monde
Posté par ElectronLibre63 . Évalué à 3.
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 pulkomandy (site web personnel, Mastodon) . Évalué à 2.
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 aiolos . Évalué à 3.
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 oinkoink_daotter . Évalué à 2.
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 :
[^] # Re: Un monde
Posté par Maxime Ritter (site web personnel) . Évalué à 2.
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 Liorel . Évalué à 10.
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 fcartegnie . Évalué à 3.
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 Anthony Jaguenaud . Évalué à 5.
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 fcartegnie . Évalué à 2.
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 arnaudus . Évalué à 3.
Tu peux stocker 20 hashes de 3 chiffres (un par combinaison), je ne suis pas certain du tout que ça facilite une attaque éventuelle…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par j-c_32 . Évalué à 1.
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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par palm123 (site web personnel) . Évalué à 2.
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 …
ウィズコロナ
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par j-c_32 . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 20 mars 2017 à 16:57.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par j-c_32 . Évalué à 2.
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 arnaudus . Évalué à 5.
Ç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?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par arnaudus . Évalué à 3.
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?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 21 mars 2017 à 10:38.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par j-c_32 . Évalué à 3. Dernière modification le 21 mars 2017 à 13:42.
Après avoir rapidement jeté un œil à certains articles au hasard, il semblerait que tu ne les aient pas lu.
Ceux que j'ai lu justement montrent que ce n'est pas un vol de DB qui est en général visé, et qu'en général, un mot de passe "plus fort" n'aurait absolument rien changé.
(uniquement sur les 3-4 que j'ai regardé, mais cela signifie que tu as au moins pas lu ceux-là)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 21 mars 2017 à 18:45.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Zenitram (site web personnel) . Évalué à 1.
Breaking news : il a demandé A, tu as répondu B.
Ce qui tend à démontrer que A n'existe pas, ça doit être une volonté de démontrer par l'absurde j'imagine…
CQFD donc. Pas mal…
donc tu penses que les DB des banques sont piratées, mais n'a aucune preuve. Tiens, mini-Trump qui fait son "Obama m'a mis sur écoute, si si regardez la".
Donc maintenant, prouve "il faudrait un peu plus te renseigner" sur les attaques réussies sur les DBs. Sinon c'est juste du vent.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par j-c_32 . Évalué à 2.
Le commentaire auquel tu réponds dis:
Cette situation est l'usage de la DB comme source d'attaque.
Dans les articles que tu cites, AUCUN (oui, j'ai perdu mon temps à tous les passer en revue) ne sont des exemples de cette situation.
Peux-tu me donner les liens où, selon toi, les DB des mots de passe ont été ciblées ?
(au mieux, la méthode n'est pas explicitée, mais rien ne prouve que cette méthode s'attaque à la DB des mots de passe).
(et le fait que les banques ne parlent pas des attaques ne change pas grand-chose: si seulement 1% des attaques sont connues, alors, il n'y a aucune raison pour que les attaques connues soient uniquement la minorité où on ne s'attaque pas aux DB des mots de passe)
On peut prendre le problème exactement dans l'autre sens pour démontrer que ton approche affaiblit le système:
- on a un système qui permet de protéger des vols de mot de passe par espionnage
- pour augmenter très légèrement la sécurité d'un composants lui-même peu sécurisé, tu réduits à 0 la protection des vols de mot de passe par espionnage
Oui, personne ne nie que cela réduit la protection des DB (il faut être idiot pour penser que c'est ça l'argument, j'espère que ce n'est pas ce que tu prétends). Ce qui est dit, c'est que la protection des DB est très loin d'être le maillon faible.
Comme tu le dis, les hackers prennent la voie la plus simple. Et comme le prouve les articles que tu cites, déchiffrer la DB n'est pas la voie la plus simple. Vouloir augmenter légèrement la protection de la DB tout en réduisant drastiquement d'autres protections, ce n'est certainement pas intelligent. Par contre, désolé, mais réduire d'un facteur 20 la protection d'un élément peu critique pour augmenter drastiquement un élément critique (le fait de jeter un coup d'œil pour voir le code d'une connaissance et ensuite utiliser son compte à son insu est en effet bien plus critique), ce n'est pas "pas intelligent".
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par StyMaar . Évalué à 1.
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 j-c_32 . Évalué à 1.
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 foobarbazz . Évalué à 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 j-c_32 . Évalué à 1.
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 -mat . Évalué à 6. Dernière modification le 20 mars 2017 à 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 Prosper . Évalué à 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 Sufflope (site web personnel) . Évalué à 2.
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 dyno partouzeur du centre . Évalué à 2.
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 Sufflope (site web personnel) . Évalué à 4.
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 traditionnellessous-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 dyno partouzeur du centre . Évalué à 7.
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 Anonyme . Évalué à -3.
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 Prosper . Évalué à 5.
Wat… A quel moment j'ai écrit ça ?
Bah si tu le dis hein…
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Dinosaure (site web personnel) . Évalué à 2.
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 Psychofox (Mastodon) . Évalué à 4. Dernière modification le 21 mars 2017 à 09:02.
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 Psychofox (Mastodon) . Évalué à 5. Dernière modification le 21 mars 2017 à 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 pulkomandy (site web personnel, Mastodon) . Évalué à 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 Renault (site web personnel) . Évalué à 2.
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 barmic . Évalué à 3. Dernière modification le 21 mars 2017 à 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 ylsul . Évalué à 3.
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 Framasky (site web personnel) . Évalué à 2.
Au bout de 3 codes faux, ça bloque l'accès au compte.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 20 mars 2017 à 16:49.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par foobarbazz . Évalué à 3.
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 arnaudus . Évalué à 7.
Non, c'est 3 tentatives tout court. Ça me semble super-facile.
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).
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 foobarbazz . Évalué à 3.
Ç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 arnaudus . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 1.
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)
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 foobarbazz . Évalué à 3. Dernière modification le 21 mars 2017 à 01:16.
Si j'étais proche de lui je les connaîtrais…
Virement rhoooooo, t'es de mauvais poil ?
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…
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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 21 mars 2017 à 09:59.
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.
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 Faya . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 0.
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 arnaudus . Évalué à 2.
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 pulkomandy (site web personnel, Mastodon) . Évalué à 4.
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 arnaudus . Évalué à 2.
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?
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 pulkomandy (site web personnel, Mastodon) . Évalué à 2.
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 louiz’ (site web personnel) . Évalué à 2.
Crédit Agricole.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Grugru . Évalué à 1.
Crédit Mutuel aussi.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3. Dernière modification le 22 mars 2017 à 16:23.
Et CIC aussi donc, puisque c'est la même banque que le Crédit Mutuel (à un détail près, le CM appartient à ses clients, alors que le CIC n'appartient pas à ses clients mais au CM, donc indirectement aux clients du CM).
À un détail près, au CM et au CIC, ce n'est apparemment que le numéro du premier compte que quelqu'un a ouvert qui constitue son identifiant client.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Zenitram (site web personnel) . Évalué à 1.
Je pouvais pas contredire sur les autres, mais la…
On ne doit pas avoir le même CIC. (le numéro que j'ai, attribué il y a 10 ans, ne correspond à aucun des mes comptes et j'en n'ai fermé aucun)
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Grugru . Évalué à 1.
Oui, je confirme seulement le premier compte, mais a partir de n'importe quel compte, c'est assez facile de retrouver le premier numéro de compte (en tout cas moi, c'est la mème base pour tous les comptes + un numéro d'ordre).
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Blaise (Mastodon) . Évalué à 1. Dernière modification le 22 mars 2017 à 17:35.
ça ne concerne pas toutes les confédérations de Crédit Mutuel.
Pour le Crédit Mutuel de Bretagne (Arkéa), l'identifiant qui était aussi le numéro du premier compte ouvert, a été changé depuis quelques années pour un numéro a priori sans lien avec le compte.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Prosper . Évalué à 2.
Et la poste bancale.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par kna . Évalué à 2.
pas chez moi, j'ai bien un identifiant distinct du numéro de compte…
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Faya . Évalué à 4. Dernière modification le 22 mars 2017 à 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 dyno partouzeur du centre . Évalué à 1. Dernière modification le 21 mars 2017 à 00:02.
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 Michaël (site web personnel) . Évalué à 4.
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 Aeris (site web personnel) . Évalué à 5. Dernière modification le 20 mars 2017 à 13:38.
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 benoar . Évalué à 4.
C'est également le cas pour les particuliers, et depuis un bout de temps.
[^] # Re: 2FA
Posté par jihele . Évalué à 4.
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 Xavier Verne (site web personnel) . Évalué à 1.
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 foobarbazz . Évalué à 3.
Un petit appareil électronique qui dure des années… Ça va…
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).
C'est une bonne question. Je suis curieux de la réponse aussi
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.
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.
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 pulkomandy (site web personnel, Mastodon) . Évalué à 2.
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 Bayet Thierry . Évalué à 6.
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 Elfir3 . Évalué à 6.
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 Glandos . Évalué à 5.
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 pulkomandy (site web personnel, Mastodon) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 gouttegd . Évalué à 4.
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 mahikeulbody . Évalué à 3. Dernière modification le 20 mars 2017 à 18:27.
Il y a en a au moins une qui l'autorise (et qui du coup ne passe pas par un clavier virtuel) : Fortuneo.
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.
[^] # Re: Certaines le font
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Oui j'ai fait toutes les banques en ligne ou presque et je peux résumer :
Aucune de ces banques ne permet de faire des virements internationaux en ligne, et toutes demandent de faire un courrier. Moderne.
En comparaison avec les autres pays où j'ai pu ouvrir des comptes (Belgique, Luxembourg, Australie, Nouvelle-Zélande, non je fait pas le tour des paradis fiscaux ;) j'ai vécu dans tous ces pays), la France est clairement à des années de retard. Notamment au niveau des virements, en France il faut souvent attendre 24-48 heures après l'ajout d'un bénéficiaire pour lui faire un virement, et aucune possibilité de faire un virement à un compte directement juste en entrant le numéro sans l'enregistrer dans les bénéficiaires. Et la sécurité… Pfiou. Ces codes à 4 (Caisse d'Epargne) ou 6 chiffres me laissent penseur. Le fait qu'il n'y ait pas de second facteur correct (les SMS ne sont pas un second facteur correct).
ING Luxembourg proposait un porte-clé HOTP (probablement RSA), ING Belgique une sorte de calculette pour signer les transactions (puis le fameux lecteur de CB qui fait pareil). En Australie/NZ le mot de passe est long, mais le second facteur est inexistant. Westpac proposait un clavier virtuel dont les lettres ne changeaient pas de place (inutile donc), vu qu'il fallait proposer l'intégralité d'un clavier QWERTY! NAB (Australie) et Kiwibank (NZ) n'ont pas de clavier virtuel (ouf). Kiwibank a un système de questions/réponses en plus du mot de passe : on choisit 3 questions et leurs réponses (A-Z + 0-9 seulement), et après le mot de passe on doit entrer 3 caractères de la réponse à une des questions. Un peu comme un pendu. Je trouve ça totalement inutile et chiant mais bon.
Aucune confirmation par SMS de l'envoi de virements ou autres, même pour des virements de plusieurs milliers de
par jour sur une carte de débit dans un distributeur sans problème, il n'est pas rare de payer une voiture à 10.000$ en cash, personne ne fait de chèque, tout le monde utilise une app de sa banque (un autre problème, certaines ne vérifiaient pas que le certificat SSL était correct, et acceptaient les certificats même si le host ne matchait pas, ah ah) pour genre payer sa part au resto, etc. pas le même état d'esprit.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Certaines le font
Posté par Marco . Évalué à 1.
Clair que la France est en retard au niveau des virements (sans doute à cause des chèques qu'on utilise encore beaucoup en France.
De mémoire l'attente est au cas où si quelqu'un pirate ton compte tu peux réagir (la banque t'envoie un mail et un sms à la caisse d'épargne du moins pour te prévenir que tu as ajouté un compte), c'est 3 jours mais une fois ajouté c'est bon.
J'avais une fois ajouté un compte bénificiaire étranger et mon banquier m'avait appelé pour me prévenir.
Pour chaque transaction sur internet je reçois un code sur mon téléphone.
J'ai jamais compris le délire du clavier virtuel, mon mdp est plus facile à retenir que mon numéro client.
# Edgard de la Cambriole qui s'inquiète de la sécu des sites bancaires :)
Posté par Le Gab . Évalué à 5.
Ton avatar et le sujet m'ont fait sourire.
[^] # Re: Edgard de la Cambriole qui s'inquiète de la sécu des sites bancaires :)
Posté par Anonyme . Évalué à 3.
c'est pr bien planqué le magot ;)
# Des éléments de réponse
Posté par RyDroid . Évalué à 3.
[^] # Re: Des éléments de réponse
Posté par dj_ (site web personnel) . Évalué à 3.
ç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 pulkomandy (site web personnel, Mastodon) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 Marotte ⛧ . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
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).
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.
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 foobarbazz . Évalué à 5.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ah oui, l'accessibilité de ces trucs est certainement épouvantable.
[^] # Re: Mot de passe
Posté par oinkoink_daotter . Évalué à 5.
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 Alex G. . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
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 Victor STINNER (site web personnel) . Évalué à 3.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.