Re: Request for comments on security of authentication/authorisation UIs

cc'ing gnome-keyring-list gnome org

On 03/26/2014 10:56 AM, Dodier-Lazaro, Steve wrote:

Currently on the Wayland ML, a bunch of devs are discussing security
issues [0,1] and the need to restrict userland processes' privileges to
e.g., take screenshots, act as virtual keyboards or read keyboard events
for other apps, etc (basically introducing privileged interfaces that
require explicit user authorisation). We've also been discussing how the
introduction of Wayland allows for redesigning and securing
authentication and authorisation UIs.

This has led me to question the way authorisation and authentication are
currently done, and to write a couple of proposed requirements for both
tasks. I'd be very keen on hearing the opinions of various DE developers
on a blog post I've written [2], that focuses a lot on the
infrastructure needs (both in Wayland and desktop environments). I'd
also like to debate UX aspects of authorisation and authentication UIs.
As far as I'm aware GNOME Shell implements a polkit agent and so relies
on the polkit infrastructure for all its auth needs. Given the proposals
I made (which really are ideas that need experimentation and
refinement), what would fit within the GNOME way of doing things? What's
the viewpoint of the UX people in GNOME? Can you spot any missing
technical (security or UX) requirements in the post? Anything you
disagree with and want me to review?


Steve Dodier-Lazaro
PhD student in Information Security
University College London
Dept. of Computer Science
Malet Place Engineering, 6.07
Gower Street, London WC1E 6BT
OpenPGP : 1B6B1670

desktop-devel-list mailing list
desktop-devel-list gnome org

Great article (erm...I mean paper)!

I strongly urge you to watch Stef Walter's talk from this past summer's

Stef is the author of gnome-keyring (the secure storage daemon), gcr (a
set of reusable widgets to present various security-related things), and
seahorse aka "Passwords & Keys".

For one, I believe your designs rely too heavily on standard (though
well-designed & thought-out) dialogs since, as you acknowledged, that
users often have difficulty understanding context, let alone being able
to make proper security decisions.

I believe that the solution to better security understanding lies in
innovative UI interactivity. Stef talks about this more in depth in his
talk, and you seem to allude to it:

In an utopian world, the user knows which data can be affected by an authorisation (e.g., whether their 
bank website currently on screen will appear on a screenshot, which files’ content can be leaked to an app, 
etc.) so s/he can make a `blink of an eye’ decision; the effects of authorisations should be tangible

But as an example, if an app would like to capture screen contents
outside its borders, it would express this desire to privilege moderator
(e.g. the wayland compositor?), which would then offer controls to the
user so that they may define the area permitted to the app.

Additionally, there should probably be one more requirement added to
This being the ability for a non-privileged application to access stored
secrets (e.g. passwords stored in a password manager).
To provide another example of how to actively integrate the user into
this security-granting action, the app (say, a web browser) would issue
a call to, e.g., the compositor which would somehow present the list of
the user's saved passwords, and the user would actively have to double
click the password for the particular username/website (in addition,
perhaps the app could tell the compositor the desired username/website,
and the compositor would scroll the presented list to the suggested
password for username/website combo).

Also, you say:
Hopefully others will agree with me and I will be able to take a FreeDesktop spec out of this article

I'm unsure what kind of spec you had in mind. To me, what seems most
useful would be a standard API for a finite number of security
requirements (as in section 5 of your paper), with concrete interfaces,
AND suggested guidelines / reference implementation (gosh, that sounds
like wayland/weston...) for each of the interactive security widgets for
the requirements.

Again, thanks for the email, the article, and all this research!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]