Tandhruil a dit:

Je ne comprends pas votre obsession sur les codes PIN des banques, ils fonctionnent bien, la double authentification est active en cas de connexion à une nouvelle machine.

Pas chez ma banque, un code par SMS une fois tous les 6 mois c’est pas de la 2FA…

Après tout, il faut démonter complètement un Iphone avec du matériel de pointe pour récupérer des données verrouillées par un simple code à 6 chiffres sans double authentification.

Idem pour le PIN de carte bancaire puisque celle ci est inutilisable après 4 tentatives infructueuses.

En supposant que ce n’est pas la date de naissance de l’utilisateur ou autre donnée récupérable via OSINT, cf le message de fred42.

(quote:2115700:::1)
pour en avoir testé plusieurs dans les années 2000, jpeux te jurer que j’en ai trouvé aucun qui proposait la capture d’écran. Aucun intéret : pourquoi? à l’époque, le clavier virtuel nexistait pas pour les connexions, les virus déruisaient des données sans rien chiffrer, et personne ne parlait de piratagede BDD chez les prestas. L’école ancienne quoi. Quel interet d’une capture d’écran si aucun clavier virtuel n’existe pour taper un code secret?

Ce qui confirme mes soupçons : les banques n’ont pas adapté leur sécurité depuis les années 2000.

TexMex a dit:

Les banques sont pas trop mauvaises dans le sens ou ils se prémunissent des attaques automatisées (clavier de chiffre mélangés), mais c’est plus inquiétant quand les interfaces d’une banque ou d’une autre est quasi la même à l’exception du logo et des couleurs…

Ca ne prémunit pas des bots. Au mieux ça oblige l’attaquant à adapter son bot pour qu’il soit capable de reconnaître le clavier. Et si plusieurs banques utilisent la même techno pour le clavier virtuel alors le bot risque de marcher sur toutes ces banques.

(quote:2115744:War Machine)
J’en fais partie. Ne pas avoir fait confiance à un gestionnaire de mot de passe, ca évite les soucis comme avec Keypass actuellement. Et certainement d’autres demain.

Soit je peux retenir mon mot de passe ou du moins sa “construction” + sa “modification” pour le rendre unique, soit je ne me prends pas la tête, et je me contente de le redemander au besoin. A l’heure où les mails sont quasi instantanés, ca demande moins d’effort que de devoir chercher son mot de passe et le déchiffrer (jamais écrit en clair,mais d’une façon dont je sais le déchiffrer, et … sur une partition chiffrée)

LastPass et pas Keypass je suppose.

Si tu peux retenir la construction de ton mdp c’est qu’il a un pattern. Si plusieurs de tes mdp ont le même pattern et que disons deux d’entre eux fuitent (car les sites les gèrent n’importe comment), les outils des pirates sont tout à fait capables d’identifier lesdits patterns.

Se reposer sur le reset de mdp c’est pratique sauf pour le mdp de la boîte mail…

Le coup de stocker les mdp dans un fichier en clair dans une partition chiffrée c’est bien jusqu’à ce que tu ais un logiciel un peu trop curieux ou que ça finisse en clair dans un fichier de cache/temporaire non chiffré parce que l’OS aime bien laisser des traces partout.

Avoir un “chiffrement” des mdp stockés qu’on doit “déchiffrer” dans notre tête c’est pas simple, ça prend du temps, et si c’est mal fait c’est une comédie sécuritaire. Ca ressemble beaucoup à bricoler un algo de chiffrement perso, or en sécurité il y a l’adage “Don’t roll your own crypto” parce que en général les algos persos sont bourrés de failles.

Tout ça prend bien plus de temps qu’avoir un gestionnaire de mdp. Et si tu as peur d’un autre LastPass, ce qui est tout à fait légitime, tu peux utiliser un gestionnaire local comme Keepass et lui interdire toute communication avec l’extérieur via ton pare-feu. Comme ça même si demain le code de Keepass est compromis il ne pourra pas fuiter tes données vers l’extérieur.

Bonus du gestionnaire de mdp : S’il a une extension de navigateur (mais là c’est plus dur pour lui interdire de communiquer avec l’extérieur à moins que le navigateur le permette) tu es immunisé contre les sites d’hammeçonnage (il ne se fera jamais duper par un URL même si il est visuellement identique à celui du site légitime (oui c’est possible, surtout sur Firefox). Et l’extension sera sans doute capable de passer outre les blocages de copier/coller (en plus de ne pas laisser ton mdp dans le presse-papier, où il pourrait être récupéré par d’autres applications voire sites).

(quote:2115738:Z-os)
Et cela chaque quoi un clavier “classique” avec ce type de bot ?

“change” et pas “chaque” je suppose.
Ca ne change rien, tout comme un clavier virtuel. L’intérêt du clavier virtuel est nul, encore plus comparé à ce qu’il engendre : secret très court (sinon ça serait une horreur à “taper”) et comme d’autres l’ont dit trouver et cliquer sur les bonnes touches prend du temps, temps pendant lequel quelqu’un derrière toi à tout le loisir de regarder et noter ton secret.

Daweb a dit:

Au hazard aussi les sites / services qui imposent de changer de code régulièrement (voir très régulièrement). Du coup quand on utilise un moyen mnemothénique pour génrer un mot de passe sur mesure pour chaque service, ca ne marche plus (sauf à incrementer quelque part un chiffre, mais on ne se souvient plus où on est est)….

Et résultat dans les entreprises qui imposent cela, on voit les codes sur des post it sous le clavier (voir carrement en bas de l’écran)…

C’est exactement pour cette raison que les autorités recommandent désormais de ne pas imposer de changement régulier. Sur le papier le changement régulier des secrets c’est une bonne pratique de sécurité, mais la réalité a montré que pour le cas de l’utilisateur moyen et des mdp c’était contre productif pour les raisons que tu as listées (j’ajouterais “réutiliser le même mdp partout et incrémenter d’un chiffre à chaque changement imposé”).

Le changement régulier des secrets c’est bien quand c’est automatisé (cf par ex les certificats TLS). Côté mdp il faudrait qu’existe un standard que les sites suivent (pas gagné) pour qu’un gestionnaire puisse mettre à jour auto le mdp et ce toujours de la même manière.
Sinon ça oblige les devs du gestionnaire à créer du code dédié pour chaque site web, ce qui est une charge de travail infinie. Donc en pratique soit le gestionnaire gère pas du tout le changement auto soit c’est géré que pour certains gros sites très utilisés.

hellmut a dit:

alors c’est sûr je vous vois venir, l’acteur malveillant qui fait du ciblé sur Mme Michu et qui utilise un keylogger qui fait des screenshots, hahaha il va lui poutrer son compte. et là je sors la carte probabilité. la probabilité qu’une telle menace s’applique à Mme Michu qui doit avoir un compte chèque et un livret avec 5000 balles dessus, elle est ridicule. et si Mme Michu a activé le 2FA pour les virements, là on tend vers 0.

le mec qui veut tirer des sous à la mère michu, il a plus vite fait de lui demander directement des sous en lui faisant croire qu’il l’a chopée en train de mater du porn et qu’il va tout balancer à ses copines du club de bridge. en plus il peut aussi envoyer le même mail à tout le club, avec un peu de bol il aura plusieurs virements sans s’adonner à des activités de haxxor.

Tout à fait, donc le clavier virtuel n’apporte rien, est une perte de temps et diminue même la sécurité (shoulder surfing, pas possible d’utiliser un gestionnaire de mdp…).
Si le keylogger est une probabilité quasi nulle ça ne sert à rien de mettre en place un dispositif supposé le contrer. Si les banques le mettent en place c’est qu’elles considèrent que la menace est réelle. En résumé elles sont à côté de la plaque soit sur la menace soit sur la contre-mesure

Iroise29 a dit:

Firefox (102.7.0esr) m’affiche : “Attention : risque probable de sécurité Firefox a détecté une menace de sécurité potentielle et n’a pas poursuivi vers www.xn–80ak6aa92e.com. Si vous accédez à ce site, des attaquants pourraient dérober des informations comme vos mots de passe, courriels, ou données de carte bancaire.”

Il détecte bien l’adresse cachée.

Pas moi… Testé sur un nouveau profil vanilla (via about:profiles) sur Windows et Linux, version 109.0 :/
Ca te le fait sur un profil vanilla ? Peut-être que tu as activé un paramètre de sécu qui ne l’est pas par défaut.

TheKillerOfComputer a dit:

Catastrophique, je n’ai pas… mais j’ai bien un cas léger à partager : Ubisoft Store/Connect.

J’ai crée un compte en 2011 avec un mot de passe de 20 caractères généré par Keepass.

Un soir de 2013 il ne fonctionnait plus (j’ai laissé une note) et j’ai essayé plusieurs fois sans succès. Avant de réinitialiser et m’étant déjà dit que l’incompétence crasse progressait en informatique, j’ai eu l’idée stupide de tester en retirant les 4 derniers caractères de mon mot de passe…

…et ça a marché.

J’ai donc profité pour le changer et je constate la chose : Ubisoft avait réduit les critères de création. Il faut 8 caractères minimum, mais 16 maximum. Pendant longtemps c’était SANS caractères spéciaux mais il semble qu’ils ont ajouté cet impératif entre 2017 (mon MDP actuel) et aujourd’hui.

Pour autant à ce jour c’est toujours 16 caractères maximum. A priori c’est encore bon mais je ne vois pas ce que ça leur coûterait de mettre 32 max.

Tu es pas le premier sur ce fil à faire part de cette expérience. En tant que développeur web je trouve ça hallucinant de stupidité d’avoir des critères de validation du mdp sur le formulaire de connexion.
Ca ne sert à rien mis à part embrouiller l’utilisateur. Ca devrait être uniquement sur le formulaire d’inscription, celui de modification du mdp et celui de réinitialisation de ce dernier.
Dans la plupart des cas en plus c’est sur des sites codés avec les pieds où lesdits critères ne sont pas centralisés donc chaque formulaire a les siens et un classique c’est le formulaire d’inscription qui n’accepte pas tels critères mais celui de modification/réinitialisation oui, parce que les devs ont oublié de modifier les critères partout… D’où l’intérêt de les centraliser : il n’y a qu’un endroit où il est nécessaire de les modifier et ça assure leur homogénéité sur tout le site.

La limitation du nombre de caractères n’a aucune pertinence au niveau technique à moins que le mdp soit stocké en clair, ou hashé via un algo daubé qui ne gère que très peu de caractères. Dans les deux cas c’est une grave faute de la part du site côté protection des données.
Ah, si, seul autre cas à ma connaissance : 72 caractères max si le mdp est hashé via bcrypt (qui était l’état de l’art jusqu’à il y a peu mais reste efficace), car ce dernier tronque au delà de 72 bytes. D’ailleurs en réalité c’est donc pas forcément 72 caractères mais peut-être moins car certains caractères comme les accentués font plusieurs bytes et pas un. Mais bon va expliquer ça à l’utilisateur, autant lui dire que c’est max 72 caractères et croiser les doigts pour qu’il aille pas au bout ou s’il y va ne se rende pas compte que la fin est peut-être tronquée quand même.

alphacentauris a dit:

C’est pourtant pas sorcier d’utiliser l’équivalent de sanitize : on évite le problème d’injection.

Je n’ai pas saisi, tu fais référence à quoi ? Au mdp ? Il n’y a pas besoin de le sanitize étant donné qu’il est hashé avant de finir en bdd, donc pas d’injection possible.
D’ailleurs sanitize c’est pas super car si tu oublies de le faire une seule fois dans ton code tu es foutu. La bonne pratique depuis de nombreuses années c’est les requêtes préparées. Sanitize est recommandé par OWASP uniquement si toutes les autres méthodes plus sûres ne sont pas possibles.

En ce qui concerne le nombre de caractères, ce n’est pas un problème, si on fait un hash solide de la valeur, car seul le hash sera transmis.

Transmis où ? Au serveur ? 99% des sites hash le mdp uniquement côté serveur donc après “transmission”.
Le hasher côté client puis côté serveur peut-être risqué (exemple), mixer les algos de hash étant mal vu. Sans parler de la problématique de la config de l’algo et de l’éventuel sel qui peuvent être l’une comme l’autre différents selon l’utilisateur et donc permettre à un attaquant de faire une énumération d’utilisateurs si on lui sert des données différentes en fonction de l’email qu’il entre.
Le hasher uniquement côté client permet l’attaque “pass the hash”.

Je crains qu’il va nous falloir encore un certain temps avant d’avoir un nombre de sites qui respectent des règles élémentaires de sécurités, bien que ça s’améliore… lentement.

C’est certain. D’autant que chez beaucoup de sites même à jour côté algo on a tendance à trouver en bdd plein de hashes qui ne sont eux pas à jour : On ne peut pas rehash le mdp de l’utilisateur avec le nouvel algo à l’état de l’art s’il ne se reconnecte pas, et le service marketing risque de s’opposer à un reset global du mdp des utilisateurs (supprimer tous les hashes pas à jour et leur envoyer un email pour les inviter à reset leur mdp) car ça pourrait ternir à tort la réputation du site, les utilisateurs pouvant penser qu’il y a eu un piratage massif et que le site essaie d’étouffer la chose, par exemple.
On a vu le cas récemment avec EDF qui s’est faite allumer par la CNIL car beaucoup de hashes en bdd étaient en MD5 ou SHA1 pas salé et ce alors que EDF avait “modernisé” le stockage du mdp depuis. Bon, modernisé mais toujours pas assez : C’est sacrément la honte en 2022 de se targuer de faire du SHA-256 ou 512 (on ne sait même pas, ils se contredisent) salé depuis 2017-2018 (là aussi ils se contredisent) comme si c’était une innovation alors que ça fait plus de 10 ans que MD5 comme SHA c’est considéré inadapté pour hasher des mdp…

S’authentifier est aussi un hashage lent plutôt que rapide. Sinon tu n’utilises pas la bonne techno.

Côté PIN chez la banque j’ai un argument contre : En cas de fuite de la bdd de la banque, même si le PIN est hashé ça sera vite brute force compte tenu du nombre très faible de possibilités. Donc si un attaquant peut récupérer la bdd d’auth d’une banque il peut ensuite se faire passer pour tous ses utilisateurs.
En pratique c’est surtout ce genre de brute force (hors ligne) qui est à craindre plus qu’un brute force en ligne (notamment car en général il y a des contre mesures comme verrouillage au bout de n essais).

Mais bon pour ma part c’est plutôt la bêtise du clavier virtuel qui me dérange surtout qu’il n’a aucun intérêt. Le code PIN n’est qu’un résultat du clavier virtuel : taper un vrai mdp en cliquant sur un clavier virtuel serait une purge.

De toute façon j’ai l’impression que les banques ont pour logique que la sécurité des comptes clients importe qu’à moitié car même en cas de fraude elles ont des assurances et des dispositifs en place pour annuler les transactions et compagnie.

Y a bien des pays où ta CB a même pas de PIN pour payer et ce quel que soit le montant… Parce qu’ils comptent sur les assurances en cas de problème.

oui oui “cryptées” et pas chiffrées

Non.

(reply:2115928:ʟ·ɪɴᴀᴅᴀᴩᴛé)
Ce n’est pas choquant si tu es obligé de changer le mdp à ton prochain login. Ca le serait s’ils t’envoyaient le mdp que tu as choisi. Surtout s’ils te l’envoient quand tu demandes un reset, car ça signifie qu’ils y ont accès en clair, ce qui ne doit pas être le cas.