After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656956 - Design for in gnome-keyring prompting via shell system modal dialogs
Design for in gnome-keyring prompting via shell system modal dialogs
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: prompting
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks: 652459
 
 
Reported: 2011-08-20 14:56 UTC by Stef Walter
Modified: 2012-01-10 15:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stef Walter 2011-08-20 14:56:46 UTC
This bug documents design discussion and decisions for the gnome-keyring gnome-shell prompting: bug #652459

For starters, I agree with people that the current gnome-keyring prompts have too much info (in their expander).

I think the overriding principle should be that password prompts should be avoided as much as possible. In general, where possible, we should be trying to find ways not to prompt the user, or if we do prompt them provide the option not to prompt them again.

After thinking about this a bit, here's what I've come up with. But if a more experienced designer has changes they'd like to see please speak up.

--------------------------------------------------------------

  Description of what the password is needed for

  Password: [ xxxx              ]

     /Possilbe warning here: ie: previous try invalid/

  [x] Possible choice here, to save this password if poss

--------------------------------------------------------------

Notes:

 * Options to change the length of time that the password is cached should
   probably go into seahorse. ie: go into properties for a keyring, and 
   then change options there.

Open Questions:

 * The biggest question I have is whether we should trend to using system
   modal dialogs (ie: in the shell) for most password prompting? What is the
   criteria between an application prompting for a password, and the 'system'
   prompting for a password?

 * Do we need to inform the user which application is requesting the password?
   This information is not always easily available?

 * Do we need to tell the user how long this password will be cached for?
   Probably not.
Comment 1 Stef Walter 2011-10-02 10:50:30 UTC
Thinking about the first question above ... Some of the gnome-keyring prompts probably shouldn't be system modal:

 * Enter master password for new keyring
 * Enter original/new password when changing keyring master password
Comment 2 Stef Walter 2011-10-03 15:19:46 UTC
Related discussion in #gnome-shell:

<cosimoc> stefw, hey, regarding your keyring/system dialogs bug, which kind of password prompts is gnome-keyring supposed to emit?
<stefw> hmmm, incomplete set: unlocking keyrings, creating keyring, changing keyring password, ssh key password, gnupg key password
<cosimoc> stefw, okay, so I guess the most visible interaction in the common case would be ssh/gnupg
<mclasen> I guess unlocking  and ssh are the big ones, right ?
<stefw> i imagine unlocking, gnupg and ssh are the ones that would go in the shell.
* mclasen doesn't think he's seeing any of the others with any frequency
<stefw> as i mentioned in the bug, i don't think that the others make sense as system modal dialogs
<cosimoc> unlocking is usually needed only with auto-login, right?
<stefw> right, that's the only one user's can't make "go away"
--> AppelonD (~AppelonD@0x5551c026.adsl.cybercity.dk) has joined #gnome-shell
<stefw> in general we want to always have a checkbox that does: save this password and don't ask me again
 but auto-login is the one place we can't
 unless we prompt the user to set an empty password on their keyring?
 perhaps
 actually, which reminds me of another sad case :(
 if the user auto-logs in when there's no keyring at all (first time ever), then when an application wants to store a password we have to make a keyring and prompt the user for a password.
 so i guess that would be a system dialog too.
 which means we have to handle original/confirm password logic
<cosimoc> couldn't we ensure the keyring is created together with the user?
<stefw> perhaps in some cases, but there are so many ways to create a user
<cosimoc> yeah, not so many to create one and enable autologin though maybe?
<stefw> perhaps. which method are you referring to?
 fingerprint logins are another issue
<cosimoc> User Accounts CC panel
<stefw> in both cases first login could be without a password.
 cosimoc: often the first and only user is auto-login too, no? created through the installer?
 or maybe that "first time install" thingy could do it?
 who's working on that?
<cosimoc> stefw, mclasen was
<stefw> yeah, maybe if no keyring is created: "(o) store my passwords encrypted / with this password: [    ]"
 and "(o) store my passwords unencrypted"
 on a pane
 in that assistant, or whatever it is.
<cosimoc> stefw, I think we should always avoid exposing the keyring creation process if possible
<-- AppelonD has quit (Ping timeout: 600 seconds)
<stefw> right, that pane could be hidden if a keyring was created by the pam module (ie: the user logged in with a password).
 the overriding principle is to not show any of these prompts unless necessary.
<cosimoc> stefw, I also think that wizard is supposed to run before the first login ever
<stefw> i see, so it creates the user account?
<cosimoc> so you could ensure a keyring is created from within the wizard itself for the user it creates
<stefw> i guess so
<cosimoc> if the user is created by other means (say 'useradd'), I think it's fine to prompt for a keyring to be created after the first login
<stefw> right, so the question is whether than login should be a system dialog
 integrated with the shell or not.
<cosimoc> heh, I don't know :)
--- hughsie is now known as hughsie-afk
<cosimoc> stefw, though I think doing a fingerprint login just to see a system modal dialog afterwards asking you for a password is not a good thing
<stefw> cosimoc: so you'd rather see a app style dialog?
 because it's a bit of an intractable problem.
 the problem of showing the dialog
 gnome-keyring isn't authenticating the user, it's trying to decrypt some passwords
 and all the apps want passwords right after logging in :(
<cosimoc> I don't want to see any dialog at all if I do a fingerprint login...don't know what are the technical challenges there
<stefw> challenges
 there's no secret to use to decrypt the keyring from a fingerprint reader
 obviously the fingerprint isn't secret.
 currently the only way around it is to not encrypt your key5ring
 if the keyring password is empty, it won't prompt, but also won't encrypt on disk.
<-- sirex has quit (Ex-Chat)
<stefw> essentially the same problem for auto-login
 what would be nice ...
<cosimoc> stefw, so if the fingerprint can provide a secret to PAM, why can't it provide a similar secret to the keyring?
<stefw> it doesn't provide a secret to pam
 pam is authenticating 
 it provides a yes/no answer
 if it did provide a secret to pam, we would use it automatically and all would be happy, the children would sing in th streets.
<cosimoc> :)
<stefw> in theory there could be a solution ...
* stefw waves hands
<stefw> the fingerprint hardware would store a randomly generated secret each time a new fingerprint is initialized into the reader.
<stefw> and it would 'release' that secret only when the fingerprint was authenticated
 and then we could use that secret to decrypt stuff.
 however theory is all well and good, but that requires hardware with that capability
<cosimoc> and this needs to be done in hardware?
<halfline> doesn't the fingerprint gets scanned into a hash ?
 a bir file or somethng like that
<stefw> halfline: your fingerprint isn't secret
<stefw> no matter how it's hashed
 so it doesn't work as a key for encrypting stuff
 unless you wear gloves day and night :P
<halfline> if it's good enough to log you in...
 not sure i understand the distinction you're making
<cosimoc> stefw, so, couldn't you emulate the pam behavior?
<stefw> halfline: https://live.gnome.org/GnomeKeyring/StoringSecrets
 pam authenticates, we don't authenticate the user
 we listen in for the password, and use it hoping it's the right one.
 so if there's no password or secret, we can't do that.
 pam makes a yes/no decision, that's the essence of pam, the fact that there's a password involved is secondary.
<halfline> well sure
 but under the covers the fingerprint gets turned to a hash and compared with a saved file
<stefw> right
<halfline> i don't understand why that hash isn't okay to use 
 that's the distinction i don't get
<stefw> because it's not a secret
 each time you touch something, you leave the information about what your keyring is encrypted with at that spot.
<halfline> well sure
<stefw> so essentially the keyring would not be encrypted
<halfline> and someone could use scotch tape or wahtever to log into your system too
<cosimoc> stefw, it's the same for login, no?
<halfline> my point is if it's good enough to log in
 why isn't it good enough to unlock your keyring?
 basically if you're using fingerprint log in at all
<mclasen> I guess theoretically logging in is harmless, if all your secrets are still locked up ?
<stefw> and my point is that, if encrypting the keyring with a publicly known value, then why encrypt it at all.
<halfline> you're accepting a certain lesser degree of security
<stefw> we already have a solution for that
 if you set a keyring password to "" it doesn't encrypt, and doesn't prompt
 why?
<halfline> why are you accepting a certain lesser degree of security?
<stefw> well the word "publiclly" might be exaggerating a bit.
<halfline> because you're giving people access to your personal files using just your fingerprint
 they could cut off your finger or use scotch tape and get access to your personal files
<stefw> halfline: i guess the question then is, why encrypt the keyring at all.
<halfline> those personal files are potentially just as important as your locked secrets
<stefw> it's a good question, and one that i have to think about every so often.
 what are we protecting against
 obviously the keyring is in your home directory, so it can't be read unless someone can log in.
<halfline> right, davidz has been saying we shouldn't encrypt the keyring for a while now too
 of course he always prefaces that with we should force encrypted home directory
<stefw> heh yeah
 we encrypt it because when someone steals your laptop, they don't get all your passwords.
 obviously they do get your data
<cosimoc> also, having it fingerprint-protected is still better than nothing if I'm not paranoid about people chasing my fingers with duct tape :)
<stefw> cosimoc: why not just leave your keyring in plain text then?
<halfline> well one thing about fingerprint is, it's all over the keys of the keyboard of the stolen laptop
<stefw> so thet question is: why is having your keyring pseudo encrypted with a fingerprint hash, better than having it not encrypted at all.
<halfline> so assuming a sophisticated thief you're screwed
<stefw> since the former takes a lot of effort to get to, and we already have the latter.
<halfline> but really thiefs don't care about your data
<cosimoc> stefw, I get your point, there's no real difference
<halfline> they care about your hardware
<stefw> true
 unless it's a company laptop
<halfline> if you have important data
<halfline> then you should encrypt it in a better way than fingerprint
<cosimoc> stefw, but it still might protect you from less-experienced people
<stefw> right, but this sort of security discussion is comtpletely subjective in any case.
 it's not somewhere productive to be.
<halfline> well at the end of the day we have to look at what user experience we want
<stefw> right, and i think the "don't encyrpt my passwords" is the right user experience
<halfline> and then figure out what gymnastics and compromises we're willing to go through to get there
<stefw> for example if we notice that the user logged in without a password, we give them the option to not encrypt their passwords.
<stefw> or default to that in the first-time account thingy
<cosimoc> stefw, the thing is, security-related prompts are scary IMO
<halfline> yea i think i agree with you
<stefw> and to have an even better user experience, make that choice while creating the account.
 default to the option that "works"
<drago01> I'd rather just disalllow "user without password"
<stefw> for example if a new account is created with a fingerprint / auto-login, default to not encrypt stuff
<halfline> stefw: sounds good
<halfline> of course any proposal like this will unavoidable cause push back
 but that's the nature of change
 people don't like it until they do
<stefw> user's using fingerprints or auto-login have already made a decision for "less security" (subjective remarks, ymmv)
 so it fits in with what the user is trying to accomplish
* stefw is having a bad spelling day
<halfline> yea, makes sense
Comment 3 Stef Walter 2011-10-28 13:04:13 UTC
Design wiki page: https://live.gnome.org/GnomeKeyring/SystemDialogs
Comment 4 Stef Walter 2012-01-10 15:56:49 UTC
Implemented designs in bug 652459, although lots of the concepts discussed haven't been done yet.