IMSoP

2017-02-23 19:28:20 UTC

view on stackexchange narkive permalink

D'autres réponses ont parlé des enregistreurs de frappe et de la manière dont ils pourraient vaincre ce mécanisme, mais je peux penser à d'autres attaques contre lesquelles ils protégeraient:

En regardant les traces de graisse sur un écran tactile où quelqu'un entre régulièrement le même code. Par exemple, le code pour déverrouiller un téléphone, ou un système de portier où l'écran n'est utilisé pour rien d'autre.
Surfer sur l'épaule, où l'attaquant peut voir le mouvement de la main de l'utilisateur, mais pas ce qui est sur l'écran. Il peut s'agir d'une personne physiquement derrière l'utilisateur dont la vue est partiellement obstruée, ou d'une caméra qui n'a pas l'écran dans son champ de vision.

Je pense que le positionnement relatif a une certaine incidence.Je suis avec vous, cependant - il semble que quelque chose dont un "pirate de cinéma" profiterait.

Si par exempleun clavier à dix chiffres est principalement utilisé pour entrer un code de sécurité à six chiffres, en observant que six touches sont portées réduirait l'espace de recherche de 1 000 000 possibilités à 720. Si cinq étaient portées, le nombre de possibilités (en supposant un code à six chiffres) serait 1800 ou 360, selon qu'il était évident quel bouton a été utilisé deux fois.Je ne sais pas qu'un écran tactile souffrirait normalement de tels problèmes, mais les claviers le peuvent certainement.

Ralentir les gens et leur faire parcourir les chiffres n'est peut-être pas le meilleur moyen de se protéger du surf des épaules.

@JonHanna Bien sûr, ce n'est pas infaillible, mais si vous ne pouvez pas voir l'écran, peu importe le temps qu'il faut à quelqu'un pour trouver les bons boutons, car vous ne savez toujours pas sur lesquels ils ont appuyé.Ils peuvent passer 5 minutes et appuyer sur le coin supérieur droit, mais lorsque vous arrivez à l'écran, un bouton différent se trouve dans le coin supérieur droit, vous n'avez donc rien appris.

@IMSoP et avec la plupart des systèmes, ils peuvent tenir leur portefeuille sur leur main et le saisir rapidement et vous avez encore moins appris.

Lie Ryan

2017-02-23 18:04:32 UTC

view on stackexchange narkive permalink

L'utilisation d'un clavier logiciel aléatoire pour la saisie du mot de passe est basée sur l'idée fausse qu'elle peut empêcher les enregistreurs de frappe. Cela peut empêcher un enregistreur de frappe matériel de capturer les données de connexion.

Dans un sens faible, il empêche également certains enregistreurs de frappe logiciels naïfs de capturer les données de connexion, mais comme vous l'avez correctement mentionné, un enregistreur de frappe légèrement meilleur peut prenez également des captures d'écran pour contourner cette mesure, et une mesure plus sophistiquée peut simplement installer un module complémentaire de navigateur pour capturer le mot de passe avant qu'il ne soit envoyé au serveur.

Étant donné que l'enregistreur de frappe matériel est beaucoup plus rare que enregistreurs de frappe logiciels, dans la plupart des sites où un tel clavier logiciel aléatoire est implémenté, ce n'est vraiment qu'un signe que le développeur n'a aucune idée que de telles mesures sont inefficaces contre la plupart des enregistreurs de frappe.

Cependant, il est efficace contre les enregistreurs de frappe «non privilégiés», c'est-à-dire les applications mobiles qui utilisent la force du signal sans fil ou les informations d'accéléromètre pour déduire des informations de position tactile.De nombreuses applications disposent de privilèges suffisants pour interroger l'une ou les deux, et il s'agit d'une menace courante dans la nature.

Cela peut également être un comportement de signalisation.Les utilisateurs désemparés peuvent être convaincus que la page Web a des mesures de sécurité beaucoup plus faciles en utilisant quelque chose comme ça que par d'autres mesures moins visibles.

Sur les téléphones, si vous entrez un mot de passe assez souvent, vous pouvez voir l'huile de doigt si vous faites pivoter l'appareil juste à droite.Cela ne vous donne pas le code réel, mais cela vous donne des nombres probables.Cette méthode écarte cela (bien que par obstruction)

@Martijn C'est ce que j'ai dit dans ma réponse;si je ne l'avais pas fait, vous auriez pu l'afficher vous-même comme une nouvelle réponse.Les commentaires sur les réponses visent à clarifier ou à remettre en question cette réponse particulière, et non à discuter de la question en général.

@SimonRichter Je n'avais aucune idée que c'était une chose.Existe-t-il des applications Android "Good guy" qui le démontrent?J'aimerais le voir en action.

Serge Ballesta

2017-02-23 20:25:15 UTC

view on stackexchange narkive permalink

Ceci est couramment utilisé par les banques. Comme déjà expliqué, il offre une sécurité supplémentaire contre les enregistreurs de frappe. Il empêche également le mot de passe d'être directement stocké dans le navigateur, ce qui est une mauvaise pratique de sécurité si aucun mot de passe principal n'est utilisé. Il convient de noter de toute façon que cela présente un inconvénient important: cela empêche l'utilisateur d'utiliser un long mot de passe aléatoire stocké dans un gestionnaire de mots de passe.

La raison en est que les banques ne font pas confiance aux utilisateurs pour pouvoir de choisir et de gérer des mots de passe forts, donc au moins ils s'assurent que l'utilisateur n'a pas stocké son mot de passe dans le navigateur sans mot de passe maître.

TL / DR: il n'ajoute aucune sécurité pour les utilisateurs réellement concernés par best pratiques de sécurité, mais cela limite les pires pratiques de sécurité que trop d'utilisateurs appliqueraient.

Je pourrais voir que cela est utile s'il s'agit du code PIN dans une approche mot de passe + code PIN, où vous devez connaître les deux.Faites-en la solution de secours si l'utilisateur refuse d'activer le réel à deux facteurs;au moins, il y aurait autre chose qui est un peu plus difficile à capturer.Dans un monde où les gens réutilisent constamment les mots de passe, il peut suffire de protéger un compte bancaire d'un mot de passe partagé qui a été compromis sur un autre site.

Ryan Kelso

2017-02-23 18:00:15 UTC

view on stackexchange narkive permalink

Il ne s'agit en réalité que d'une protection contre un enregistreur de frappe, car les enregistreurs de frappe peuvent désormais capturer à la fois vos frappes et les informations de mouvement de votre souris, donc en déplaçant les chiffres à chaque fois, cela rend les données enregistrées au clavier inutiles car ils ne sauront pas quel numéro vous enfoncé.

Comme vous le dites - efficace contre l'enregistreur de frappe uniquement si vous utilisez réellement une souris.Mieux vaut simplement utiliser un OTP ou 2FA.

Dennis Jaheruddin

2017-02-24 20:49:29 UTC

view on stackexchange narkive permalink

1. Il est plus difficile d'automatiser l'entrée

La dernière fois que j'ai vu cela, c'était sur un site de jeu où les gens avaient tendance à laisser des robots triviaux jouer pour eux. Si vous avez un emplacement traditionnel pour l'entrée de la broche, vous pouvez simplement programmer le bot pour copier la broche, ou cliquer sur les emplacements désignés.Maintenant, quelqu'un devra soit rendre son bot plus intelligent (peut-être même plus intelligent que le minimum nécessaire pour jouer au jeu) avant de pouvoir jouer au jeu. serait capable d'exécuter le jeu entièrement automatisé.

Suivant la même logique, cela pourrait également être utilisé pour rendre le craquage par force brute plus difficile, mais là, la limitation devrait faire l'affaire, donc je ne pense pas que ce soit le pensée sous-jacente.

2. Cela décourage les gens de choisir des codes d'accès triviaux

Bien que je ne sois pas sûr que ce soit l'objectif principal, cela a certainement été un effet pour moi.

J'ai récemment utilisé une application là où je l'ai fait ne se soucie pas vraiment de la sécurité, et a envisagé de choisir 1111 comme code pour chaque compte car ce serait facile à choisir et à saisir.

Cependant, la randomisation des clés m'a fait réaliser que

Cette épingle est importante (même si c'est juste un petit peu)
Il ne serait pas plus rapide de saisir 1111 que quelque chose comme 1835

En conséquence Je me suis retrouvé avec un code PIN un peu moins trivial.

Les vérifications sont côté client, donc # 1 s'applique uniquement à l'automatisation côté client.Le processus ralentit également les utilisateurs qui entrent leur mot de passe, ils sont donc plus susceptibles de simplifier leur mot de passe (donc # 2 n'est pas vrai).

Le point 2 est basé sur une exigence de longueur fixe (par exemple, une broche à 4 chiffres).