Suite à mon article de blogue et journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?, je reviens vous prévenir de la sortie d'un autre article lié à la sécurité de la pile graphique Wayland.
Cette fois ci, cet article a été écrit par Steve Dodier-Lazaro, doctorant en "Usable Security" à l'University College of London (UCL), et se concentre sur le problème de sécurité lié au fait que n'importe quelle application peut imiter les fenêtres d'autorisation/authentification telles que celles de gksudo/kdesu/etc qui demandent le mot de passe utilisateur ou administrateur. Une application malicieuse pourrait ainsi récupérer des mots de passe très facilement.
Pour l'anecdote, une partie de l'article élabore sur l'idée de la moule LinuxFR GaMa qui avait proposé en commentaire de mon journal précédent une solution à ce problème. Merci GaMa!
L'article est disponible sur mon site à cette adresse. Les commentaires et idées sur comment représenter visuellement certains types de privilèges sont particulièrement bienvenus !
# hash visuel
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cette idée de présenter une image, me rappelle mon idée de hash visuel.
L'idée serait de faire une application comme sha256sum qui rend une image au lieu d'une somme de contrôle.
Je pensais générer en interne un hash 256 ou plus, puis utiliser les bits en question pour créer une fractal de julia (coordonnées : 2 nombres 32 bits + 2 nombres pour le zoom, nombre d’itérations : 8 bits), générer une palette de couleur (3*3 nombre 8 bits), on peut aussi imaginer des cadrages différente ou des rotations, mais l'entropie ajouté serait faible.
Le but est évidement de rendre impossible la création d'une image proche d'une autre, comme pour les hash classique.
"La première sécurité est la liberté"
[^] # Re: hash visuel
Posté par Martin Peres (site web personnel) . Évalué à 3.
Oui, c'est l'idée, mais personnellement, je ne pense pas pouvoir me souvenir des hashs pour chacune de mes machines :s Cependant, ça sera mieux que rien et faudrait rendre ça remplaçable par une image choisie par l'utilisateur!
[^] # Re: hash visuel
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Si l'image est vraiment marquante, notement ses formes et ses couleurs dominantes, cela doit pouvoir ce faire.
Cela peut aussi être le hash d'un objet commun entre toutes les machines (clef ssh ?). J'imagine qu'il doit exister des protocoles qui évitent de stoker l'information en dur, et la recalculer à la volé, ce qui éviterait le vol de l'image.
"La première sécurité est la liberté"
[^] # Re: hash visuel
Posté par Martin Peres (site web personnel) . Évalué à 3.
Dans ce cas là, tu places la sécurité sur la confidentialité de l'algorithme de génération du Hash (à moins que le calcul soit fait à partir de paramètres uniquement accessibles par le processus qui générera le hash).
Ça semble donc être mauvaise idée. Je pense vraiment que la machine doit stocker de façon confidentielle l'image (qui sera générée à partir de /dev/urandom à la création du compte).
[^] # Re: hash visuel
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Tu bases la sécurité de l'image sur une fonction de hash connu (sha256 par exemple), et le caractère chaotique et imprédictible des fractales.
Jusqu'à preuve du contraire, le sha256 et sha3 ne sont pas cassé, et l'imprédictibilité des fractales est un problèmes de math connu.
"La première sécurité est la liberté"
[^] # Re: hash visuel
Posté par Martin Peres (site web personnel) . Évalué à 3.
Une fonction de hash connue est en effet ce qu'il faut utiliser. Je réagissais juste à cette partie:
Et c'est là que j'étais pas d'accord car ce qui est utilisée en entrée de la fonction de hash doit être inconnu, sinon tout le monde peut re-générer la même image.
[^] # Re: hash visuel
Posté par Steve Dodier-Lazaro (site web personnel) . Évalué à 3.
Et il faut aussi que cette variable inconnue ne change jamais pour toute la durée du compte ! On pourrait par exemple imaginer utiliser l'identifiant de l'utilisateur et le hash de son mot de passe (si on veut donner accès a /etc/shadow a l'UI d'authentication…), mais alors un changement de mot de passe change aussi l'image.
[^] # Re: hash visuel
Posté par Steve Dodier-Lazaro (site web personnel) . Évalué à 5.
Ça existe et a été suggéré dans les commentaires de l'article: Identicons. Il y a donc des algorithmes utilises pour générer des formes géométriques simples, utilisées par exemple par WordPress pour donner un avatar unique aux commentateurs base sur leur adresse IP.
C'est assez facile de les distinguer les uns dans autres si plusieurs sont affiches, mais il n'y pas de preuves solides que quelqu'un puisse arriver a reconnaître son avatar de manière systématique. En ce sens l'image choisie par l'utilisateur me semble être une meilleure idée.
[^] # Re: hash visuel
Posté par barmic . Évalué à 3.
C'est un peu ce qu'utilise openssh pour vérifier les fingerprint, non ?
http://security.stackexchange.com/questions/44974/visual-fingerprint-verification
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# however however
Posté par maboiteaspam . Évalué à 2.
Ou alors tu whitelist les applications certifiable (le troisième œil), tu leurs appliques alors un affichage de boite standard.
Pour toutes les autres demandes tu présentes une boite vraiment alarmante de sorte que l'utilisateur soit conscient.
L'idée étant ensuite de sécuriser l'affichage de la boite de dialogue standard pour les applications whitelister, et là je me demande si il n'est pas possible de hasher l'affichage de la boite à l'écran ?
Si l'affichage de la boite, contenait le nom de l'app, son chemin d'accès, voir sa somme chiffrée, alors en quelque sorte chaque affichage de boite de dialogue est unique et donc comparable afin d'identifier l'application qui se prétend être whitelister.
Et si il s'avère qu'elle ne l'était pas la sanction devrait mécaniquement et sévèrement tomber puisque l'application tenterait de manipuler l'utilisateur à son insu.
Reste plus qu'alors à hoster la whitelist de manière sécurisé, et la bien qu'internet soit une idée, c'est peu fiable malgré tout, je ne sais pas trop.
bref, c'était une idée, probablement déjà envisagée ?
# Screenshot du secret de l'utilisateur
Posté par Xinfe (site web personnel) . Évalué à 1.
Je viens de me demander : dans le cas où une image secrète (ou phrase secrète) est affichée à l'utilisateur pour bien prouver que la fenêtre d'auth est conforme, qu'est ce qui empêche une app de screenshot de découvrir ça ?
Par exemple, je télécharge un utilitaire de screenshot avec des fonctionnalités avancées bien cool. Il demande les droits, je les lui accorde. Qu'est ce qui empêche qu'au moment opportun, il fasse une copie de l'écran lorsqu'il y a une fenêtre d'auto légitime pour la copier et en forger une fausse pour l'utilisateur ?
Si la solution est d'interdire les screenshots des fenêtres d'auth, ça va être pratique de faire des tutoriaux ou de l'administration à distance via VNC ou autre (comme ça peut se faire en entreprise).
Merci pour l'article, c'est une problématique plus complexe que ce que j'imaginais au début !
[^] # Re: Screenshot du secret de l'utilisateur
Posté par lolop (site web personnel) . Évalué à 2.
Sur les accès un peu particuliers à l'interface graphique, il faut aussi inclure tous les systèmes d'aide pour les handicapés (navigation, agrandissement des éléments, synthèse vocale, etc).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.