GNOME Bugzilla – Bug 656956
Design for in gnome-keyring prompting via shell system modal dialogs
Last modified: 2012-01-10 15:56:49 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.
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
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
Design wiki page: https://live.gnome.org/GnomeKeyring/SystemDialogs
Implemented designs in bug 652459, although lots of the concepts discussed haven't been done yet.