Re: Prompting for passwords on the desktop?
In terms of User Experience I've grown to love the mac style sheet dialog [1] for password prompts. It's not often that I'll recommend a dialog, or a modal dialog for user interactions. However sheets seem to have most of the properties you want when a password is required from an application. If an application requires a password it's one of the few times an application absolutely cannot continue; however it can be problematic, if not dangerous, if that password dialog is floating around away from the application that requires it. Sheets keep the dialog pinned to the parent application that called them and so increases a persons awareness of what is requiring a password. Of course there are other issues in OS environment that means you need more than a sheet dialog. For example notification icons could require a password. I think it would make sense to look into designing "notification sheets" for this problem. It still strikes me as weird when I logging into my Desktop that "something" requires my keyring password, that "something" being NetworkManager, I don't really think the darkening of the screen dialog modality is really a good path towards a usability / security balance. If anything this takes away from your ability to understand what is requiring a password. The windows Vista UAC dialogs are great examples of how the application information needs to be duplicated by showing it's name and icon inside the dialog because the person can't see the application that called the dialog. I'm sure that answer isn't too helpful as I'm aware we don't currently have sheets, but you know how we designers love to ask for the moon. :) ~ Bryan [1] http://en.wikipedia.org/wiki/Sheet_dialog_box On Mon, Sep 22, 2008 at 12:03 PM, Brian Cameron <[EMAIL PROTECTED]>wrote: > > Note that the Windows solution to use Ctrl+Alt+Del as a Secure Attention > Key is just one way to implement Trusted Path. There is no reason that > the GNOME or UNIX community couldn't come up with a different and novel > way to meet the same requirements. The Secure Attention Key should be > viewed as just an example of how Trusted Path requirements can be solved > and the solution as used by Windows (along with Kerberos). > > Debating about whether we should use the same sort of solution, or a > different solution makes for good discussion, but I don't think it > makes sense to suggest that just because this particular solution has > usability issues means that Trusted Path requirements are somehow > invalid or inappropriate for UNIX environments. > > Even though some might suggest that security is "good enough" on > Linux without meeting these requirements, it still is a good idea to > consider how to make GNOME and UNIX more secure. Whatever solution > might be decided upon will likely require enough infrastructure > enhancements that we will have time to be thoughtful about the best way > to provide the feature. > > Brian > > > > But I'm no security expert; I might be missing something. >>> I believe the goal is to use some uncatchable keyboard sequence a'la >>> Windows' secure auth (Ctrl+Alt+Del). >>> >> >> This works on Windows (on a domain) because the goal in those situations >> is to have perfect and total single sign on. This has been watered down >> in more recent (less coherent) Windows releases, but the goal was always >> to prompt the user once and never prompt them again for any application >> because the system uses kerberos. >> >> In our mix of applications and protocols passwords abound, and it's less >> likely that a Ctrl-Alt-Del style solution would be sufficiently usable. >> >> Cheers, >> >> Stef Walter >> >> > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Note that the Windows solution to use Ctrl+Alt+Del as a Secure Attention Key is just one way to implement Trusted Path. There is no reason that the GNOME or UNIX community couldn't come up with a different and novel way to meet the same requirements. The Secure Attention Key should be viewed as just an example of how Trusted Path requirements can be solved and the solution as used by Windows (along with Kerberos). Debating about whether we should use the same sort of solution, or a different solution makes for good discussion, but I don't think it makes sense to suggest that just because this particular solution has usability issues means that Trusted Path requirements are somehow invalid or inappropriate for UNIX environments. Even though some might suggest that security is "good enough" on Linux without meeting these requirements, it still is a good idea to consider how to make GNOME and UNIX more secure. Whatever solution might be decided upon will likely require enough infrastructure enhancements that we will have time to be thoughtful about the best way to provide the feature. Brian But I'm no security expert; I might be missing something. I believe the goal is to use some uncatchable keyboard sequence a'la Windows' secure auth (Ctrl+Alt+Del). This works on Windows (on a domain) because the goal in those situations is to have perfect and total single sign on. This has been watered down in more recent (less coherent) Windows releases, but the goal was always to prompt the user once and never prompt them again for any application because the system uses kerberos. In our mix of applications and protocols passwords abound, and it's less likely that a Ctrl-Alt-Del style solution would be sufficiently usable. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Le lundi 22 septembre 2008 à 16:02 +0200, Dave Neary a écrit : > > I really think the good criterion is not “has focus” but some “action > > triggered by the user less than 1 second ago”. > > That seems like it'll be overly complicating any code that gets written > to handle this. I didn’t mean to add some code to check that rule, since there is no good code solution for it. > Occam's razor and all that... Getting asked for a > password when writing email is annoying (it's one of my least favourite > things about Thunderbird when I'm using it off-line) but the solution is > to figure out why you're authenticating in the mail programme at the > wrong time and suppress that auth request, rather than complicate the > code path for what should be a system service. Of course, the solution is to redesign properly software doing bad things following proper guidelines, not to introduce complicated code that wouldn’t solve anything. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Hi, Josselin Mouette wrote: > Le lundi 22 septembre 2008 à 11:54 +0200, Steve Frécinaux a écrit : >> We could have such a behaviour: >> >> - if the application requesting the password is focused, then show the >> modal dialog directly. >> - if not, then have an icon in the notification area or something like that. > > That’s certainly a good start, but it is not enough. For example if you > are writing an email in evolution and it suddenly asks for a password > while reconnecting, it is quite annoying. > > I really think the good criterion is not “has focus” but some “action > triggered by the user less than 1 second ago”. That seems like it'll be overly complicating any code that gets written to handle this. Occam's razor and all that... Getting asked for a password when writing email is annoying (it's one of my least favourite things about Thunderbird when I'm using it off-line) but the solution is to figure out why you're authenticating in the mail programme at the wrong time and suppress that auth request, rather than complicate the code path for what should be a system service. Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Le lundi 22 septembre 2008 à 11:54 +0200, Steve Frécinaux a écrit : > 2008/9/18 Josselin Mouette <[EMAIL PROTECTED]>: > > One way to avoid annoying the user is to establish a line like "a > > password prompt should only pop up immediately after a user action". > > This way it appears only while you are expecting to type a password. > > > > Good behavior: you click on "send mail" in evolution, and it immediately > > prompts the GPG passphrase. > > > > Bad behavior: still in evolution, when an IMAP server stops responding, > > a pop up comes out of nowhere and asks for your password, whatever you > > were doing at that moment. > > > > Moderately bad behavior: you connect to a slow remote server in > > nautilus, and 10 seconds later it asks for a password. > > > > Of course, it looks very hard to find correct ways to implement password > > prompts without having them popping up at unexpected times, but that's > > at least what we should try to achieve. > > We could have such a behaviour: > > - if the application requesting the password is focused, then show the > modal dialog directly. > - if not, then have an icon in the notification area or something like that. That’s certainly a good start, but it is not enough. For example if you are writing an email in evolution and it suddenly asks for a password while reconnecting, it is quite annoying. I really think the good criterion is not “has focus” but some “action triggered by the user less than 1 second ago”. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
2008/9/18 Josselin Mouette <[EMAIL PROTECTED]>: > One way to avoid annoying the user is to establish a line like "a > password prompt should only pop up immediately after a user action". > This way it appears only while you are expecting to type a password. > > Good behavior: you click on "send mail" in evolution, and it immediately > prompts the GPG passphrase. > > Bad behavior: still in evolution, when an IMAP server stops responding, > a pop up comes out of nowhere and asks for your password, whatever you > were doing at that moment. > > Moderately bad behavior: you connect to a slow remote server in > nautilus, and 10 seconds later it asks for a password. > > Of course, it looks very hard to find correct ways to implement password > prompts without having them popping up at unexpected times, but that's > at least what we should try to achieve. We could have such a behaviour: - if the application requesting the password is focused, then show the modal dialog directly. - if not, then have an icon in the notification area or something like that. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Patryk Zawadzki wrote: > On Fri, Sep 19, 2008 at 12:42 PM, Gustavo J. A. M. Carneiro > <[EMAIL PROTECTED]> wrote: >> Someone who has gained a user privilege could possibly show a fake >> password input dialog that looks exactly like a "real" password prompt, >> thereby learning the root password. >> >> Same thing with VT swiching. It shouldn't be hard to make the it look >> like we are switching VT from a simple X11 program running as the user. >> >> If the local user account has been compromised it seems to me that all >> hope is lost. So I don't really see the point of all this Trusted Path >> complexity. >> >> But I'm no security expert; I might be missing something. > > I believe the goal is to use some uncatchable keyboard sequence a'la > Windows' secure auth (Ctrl+Alt+Del). This works on Windows (on a domain) because the goal in those situations is to have perfect and total single sign on. This has been watered down in more recent (less coherent) Windows releases, but the goal was always to prompt the user once and never prompt them again for any application because the system uses kerberos. In our mix of applications and protocols passwords abound, and it's less likely that a Ctrl-Alt-Del style solution would be sufficiently usable. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Josselin Mouette wrote: > Le jeudi 18 septembre 2008 à 18:46 +, Stef a écrit : >> Some people want it to act like gksudo. That is, make a password prompt >> desktop modal, no other windows are accessible, everything grayed out. >> >> Use case/complaint: "I was giving a presentation in front of thousands >> of people. I did X that caused a password prompt came up but >> gnome-keyring didn't grab the focus properly, and I typed my password in >> clear view. Now I'm screwed." > > These people are right. A password prompt should grab keyboard and > mouse, otherwise you are susceptible to leak the password. Typing wrong > stuff in a password prompt is a mere annoyance; typing a password > somewhere else is a security issue. So is the consensus that all password prompts should grab the keyboard in a big way (ala gksudo)? How would this apply to all the password prompts that applications like to throw up. Does this apply to only passwords of a certain 'caliber'? Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
On Fri, Sep 19, 2008 at 2:50 PM, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > On Fri, 2008-09-19 at 13:09 +0200, Patryk Zawadzki wrote: >> I believe the goal is to use some uncatchable keyboard sequence a'la >> Windows' secure auth (Ctrl+Alt+Del). > This is kind of silly; I have to type a complex keyboard combination in > order to input a password? That is annoying. Additionally, switching > VTs in Linux is usually slow; more annoyance. Expect some resistance on > this "feature". It's not for regular users, it's for environments with strict security policies and is the only way to ensure you are not typing the password into a spoofed prompt. The idea is to ask the user to manually invoke a "system break" that can't be captured programmatically to guarantee that the password prompt served by the underlying system, not by some random program (all non-privileged app GUIs are hidden for the time and all the grabs are temporarily disabled). I hope you understand that user-initiated super-grab is the only secure way to input anything (remember you have no control over other processes running in the userspace and have to assume they are all malicious). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
> This is kind of silly; I have to type a complex keyboard combination in > order to input a password? That is annoying. Additionally, switching It makes a lot of sense in some environments and not a lot of sense in many others. > VTs in Linux is usually slow; more annoyance. Expect some resistance on > this "feature". Actually our VT switching is incredibly fast, the X VT switching is slow and much of that is because you have to spend time waiting for PLLs to stabilize and the like not because of bad code. You wouldn't need VT switching for SAK/trusted path anyway. > Besides, my user account being compromised is 99% as bad as the root > account being compromised, IMHO. Again depends on the environment. On a home system if something is stealing your password the box is probably compromised. On a multi-user or shared system its quite likely another legitimate user who has not compromised the box is the cause. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
On Fri, 2008-09-19 at 13:09 +0200, Patryk Zawadzki wrote: > On Fri, Sep 19, 2008 at 12:42 PM, Gustavo J. A. M. Carneiro > <[EMAIL PROTECTED]> wrote: > > Someone who has gained a user privilege could possibly show a fake > > password input dialog that looks exactly like a "real" password prompt, > > thereby learning the root password. > > > > Same thing with VT swiching. It shouldn't be hard to make the it look > > like we are switching VT from a simple X11 program running as the user. > > > > If the local user account has been compromised it seems to me that all > > hope is lost. So I don't really see the point of all this Trusted Path > > complexity. > > > > But I'm no security expert; I might be missing something. > > I believe the goal is to use some uncatchable keyboard sequence a'la > Windows' secure auth (Ctrl+Alt+Del). This is kind of silly; I have to type a complex keyboard combination in order to input a password? That is annoying. Additionally, switching VTs in Linux is usually slow; more annoyance. Expect some resistance on this "feature". Besides, my user account being compromised is 99% as bad as the root account being compromised, IMHO. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> "The universe is always one step beyond logic" -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
On Fri, Sep 19, 2008 at 12:42 PM, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > Someone who has gained a user privilege could possibly show a fake > password input dialog that looks exactly like a "real" password prompt, > thereby learning the root password. > > Same thing with VT swiching. It shouldn't be hard to make the it look > like we are switching VT from a simple X11 program running as the user. > > If the local user account has been compromised it seems to me that all > hope is lost. So I don't really see the point of all this Trusted Path > complexity. > > But I'm no security expert; I might be missing something. I believe the goal is to use some uncatchable keyboard sequence a'la Windows' secure auth (Ctrl+Alt+Del). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
wOn Thu, 2008-09-18 at 22:55 -0500, Brian Cameron wrote: > Stef: > > > Is there a standard way or goal for the UI and behavior of password > > prompts on the desktop? Besides having as few as possible, that is. > > There is Trusted Path to consider. To meet Trusted Path requirements, > any entry of the root password needs to be done via a trusted user. > This means that the dialog would need to run as a special trusted user, > and not as the user whose session is running. Much like the GDM GUI > programs are run by the special "gdm" user. Otherwise, someone who has > gained a user privilege could possibly snoop process memory space to > get the root password. Someone who has gained a user privilege could possibly show a fake password input dialog that looks exactly like a "real" password prompt, thereby learning the root password. Same thing with VT swiching. It shouldn't be hard to make the it look like we are switching VT from a simple X11 program running as the user. If the local user account has been compromised it seems to me that all hope is lost. So I don't really see the point of all this Trusted Path complexity. But I'm no security expert; I might be missing something. > Also if the dialog is running as the user and > core dumps (or can be induced to core dump), then the password may be > left behind in the core file readable by the user. Also the dialog > would need to run with a separate Xauth connection to the Xserver to > protect against snooping via X interfaces. > > However, to resolve this problem would require a fairly significant > amount of infrastructure that does not exist today. Most people feel > that the existing security is "good enough", but sysadmins with strict > Trusted Path requirements would likely have to disable programs from > asking for root passwords in dialogs via programs like gnome-keyring, > PolicyKit, or gksu. > > gnome-screensaver has similar Trusted Path issues. I understand Jon > McCann is planning to fix this by making the screen lock program show > up in a separate Xserver running as a trusted user. This would work > via a mechanism similar to VT switching. Once that is done, perhaps > that could be extended so programs like gnome-keyring or gksu could use > a similar interface for added security and for meeting Trusted Path > requirements. That would also resolve a lot of the grabbing and > focus issues that plague programs asking for sensitive root passwords > in a user session. > > So this information is probably not useful in the short term, but > something to be aware of. A long-term goal should be to address these > issues so that root password entry is handled in a more secure fashion > in the future. > > Brian > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> "The universe is always one step beyond logic" -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Stef: Is there a standard way or goal for the UI and behavior of password prompts on the desktop? Besides having as few as possible, that is. There is Trusted Path to consider. To meet Trusted Path requirements, any entry of the root password needs to be done via a trusted user. This means that the dialog would need to run as a special trusted user, and not as the user whose session is running. Much like the GDM GUI programs are run by the special "gdm" user. Otherwise, someone who has gained a user privilege could possibly snoop process memory space to get the root password. Also if the dialog is running as the user and core dumps (or can be induced to core dump), then the password may be left behind in the core file readable by the user. Also the dialog would need to run with a separate Xauth connection to the Xserver to protect against snooping via X interfaces. However, to resolve this problem would require a fairly significant amount of infrastructure that does not exist today. Most people feel that the existing security is "good enough", but sysadmins with strict Trusted Path requirements would likely have to disable programs from asking for root passwords in dialogs via programs like gnome-keyring, PolicyKit, or gksu. gnome-screensaver has similar Trusted Path issues. I understand Jon McCann is planning to fix this by making the screen lock program show up in a separate Xserver running as a trusted user. This would work via a mechanism similar to VT switching. Once that is done, perhaps that could be extended so programs like gnome-keyring or gksu could use a similar interface for added security and for meeting Trusted Path requirements. That would also resolve a lot of the grabbing and focus issues that plague programs asking for sensitive root passwords in a user session. So this information is probably not useful in the short term, but something to be aware of. A long-term goal should be to address these issues so that root password entry is handled in a more secure fashion in the future. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Le jeudi 18 septembre 2008 à 18:46 +, Stef a écrit : > Some people want it to act like gksudo. That is, make a password prompt > desktop modal, no other windows are accessible, everything grayed out. > > Use case/complaint: "I was giving a presentation in front of thousands > of people. I did X that caused a password prompt came up but > gnome-keyring didn't grab the focus properly, and I typed my password in > clear view. Now I'm screwed." These people are right. A password prompt should grab keyboard and mouse, otherwise you are susceptible to leak the password. Typing wrong stuff in a password prompt is a mere annoyance; typing a password somewhere else is a security issue. > Other people hate stuff that grabs the focus. This is the exact opposite > of the above request. > > Use case/complaint goes something like: "I was shelling into a remote > computer from a terminal and a password prompt came up. Nothing should > EVER grab the focus on my desktop. My groove has been broken." One way to avoid annoying the user is to establish a line like “a password prompt should only pop up immediately after a user action”. This way it appears only while you are expecting to type a password. Good behavior: you click on "send mail" in evolution, and it immediately prompts the GPG passphrase. Bad behavior: still in evolution, when an IMAP server stops responding, a pop up comes out of nowhere and asks for your password, whatever you were doing at that moment. Moderately bad behavior: you connect to a slow remote server in nautilus, and 10 seconds later it asks for a password. Of course, it looks very hard to find correct ways to implement password prompts without having them popping up at unexpected times, but that’s at least what we should try to achieve. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
