• # however however

    Posté par . En réponse au journal Management des interfaces utilisateur d'autorisation et d'authentification sur Wayland. Évalué à 2.

    However, what really matters is the ability of the user to systematically and immediately distinguish any fake from the true UI and to associate the fake with a strong feeling of insecurity. Otherwise, spoofing may very well still occur. The solution to this is to have the authentication dialog authenticate itself to the user by presenting a secret/credential shared with the user (thanks to GaMa for inspiring this requirement). The secret should be used for that purpose, and not be one that is used to authenticate the user as this would allow shoulder surfing from physical adversaries. This means we need a way to generate such a secret when an account is created, to update or modify it, and to store it securely.

    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 ?