PIN Authentication

Design

PIN is another form of authentication, designed as a trade-off between security and ease-of-use on devices with no physical keyboard. Being inherently weaker, it is used only by local graphical logins and session unlocks.

Implementation

• A new pam stack, gdm-pin, with a special pam_gnome_shell_pin module stacked before pam_unix and the other modules.
• This module takes the PIN from the PAM conversation and uses it to decrypt the password stored in /var/lib/gnome-shell-pin/$user (using it as an AES key).
• The decrypted password is passed down the stack for the actual authentication.
• The module also takes care of creating the file using the password and the PIN (in the "password" PAM stack).
• accountsservice will be changed to use pam instead of shadow-utils for changing passwords. This will require a separate binary, as PAM in the main process is dangerous.

• (useful but not needed) A new daemon is created abstracting PAM and multiple conversations for PolicyKit, accountservice, gdm and other PAM users in our control, essentially making what gdm does now available to everyone.

IRC log of the discussion

<gcampax> the first one is with the PIN, as designed in the wiki - how is it configured, what it is used for (other than lock screen), and how to best implement it
 I had three ideas in mind (separate PAM stack, UI only concept + accountsservice boolean, unlock only concept + unencrypted GSettings)
 diegoe: no big plan related to that bug, just personal annoyance - actually categories are going away before 3.6
 diegoe: actually I didn't think the gnome-menus patch would be merged with no questions asked, but oh well :)
<marina> gcampax: I summarized some things in https://mail.gnome.org/archives/desktop-devel-list/2012-May/msg00099.html
<marina> gcampax: from jimmac's response in the thread - The pin is intended for devices where it would be easier to use a pin than a text entry, such as tablets. It will be possible to set up a pin through the Login Options in the User Accounts panel or during the initial setup.
<gcampax> marina: yep, but that only covers the UX of it, not the implementation
 in fact, one might say that for such tablets, the pin makes sense as a replacement for password always, not just for unlocking
 (thus advocating the PAM way)
 but then, what's the unix password for?
<marina> gcampax: the pin would be used on the login screen too
<gcampax> and for polkit, I would guess
<marina> yeah, I guess
 halfline: do you have an opinion on whether we should do PIN as part of PAM?
<gcampax> but it would still be an addition to unix (shadow) passwords, not a replacement?
<marina> gcampax: I guess the pin and password are alternate ways and both can be present on the system and used to unlock it, but that's my guess
<halfline> i'd say there should be some sort of pam module
 since we have to execute a pam stack of some sort to open a session
<owen_> I gues the question is defining how a pin is different from a password
<halfline> the pam module could just effectively stall though until some side band communication over d-bus finishes
 and finally just return success when that communication succeeds
<gcampax> halfline: and where would be store the PIN? session level or another /etc/shadow-like?
<halfline> are we only going to allow pins for unlocking or for starting new sessions ?
 i'd assume it would be allowed in both cases
 in which case can't be session
<gcampax> I think so (gnome-mockups has very similar screens for login and lock)
<marina> halfline: both cases; there was also talk of including set up of a pin in initial setup
<halfline> once question is, why just digits?
 why not show the on screen keyboard and allow the user to type their password?
 would need to talk to the designers and figure out the original intention
 mccann: did you add pin initially ? what was the rationale behind it?
<owen_> halfline: I think the basic idea is "weak password that is defined to be weak" - and only digits is a pretty clear way of doing that
<halfline> weak, why?
<owen_> halfline: with the idea that a strong password according to the rules generally used for strong passwords is really annoying to type on a mobile device that locks after a few minutes without a keyboard - it's a swipe-gesture alternative
 halfline: (jimmac said this somewhere - probably on the thread on ddl)
<gcampax> owen_: ok, but then it would be only for unlocking, not login
<owen_> gcampax: I'm not sure - it might not be easy for a user to understand why would they have to use a different password when they reboot their device (after updates) other than on unlock
<marina> so the tentative design here for the login screen includes the pin option: https://live.gnome.org/GnomeOS/Design/Whiteboards/LoginScreen#Tentative_Design
<halfline> sorry there's been a lot of meat space talk just now
<marina> here in jimmac's response in a thread: https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00306.html
<halfline> so the point of this according to mccann is...
 normally when you generate a password it needs to be "strong"
 we go through all these hoops to make it have variations of numbers and letters
 and symbols
 and often people come up with line noise as their password
 they don't even really remember what it is, they just remember how to type it
 this skirts right in the face of logging in with a touch screen
 you can't replay your muscle memory if you're inputing to something on screen
 so this simplified password is an alternative way to access the system
 in a subset of the cases a normal password could be used
 you should never be able to ssh into a system and type your pin code and gain access
 this access is meant for local logins via a touch screen
 so given that perspective on its intent
 we need to keep it separate from the unix password hash in /etc/shadow
<marina> halfline: thanks, that's helpful!
<jimmac> hey hey
<halfline> so one question is where can we store the password hash then?
 mclasen offered using accountsservice as a convenient place to store it
 which seems reasonable enough
<jimmac> yea it certainly isn't meant as a replacement for passwords on the old-fart form factors
<halfline> at this point davidz popped in
 and pointed out login and screen unlock aren't the only places we enter passwords
 we also enter passwords in policykit
 and suggested we unify things by moving the pam handling that's in gdm to policykit
 policykit already has some pam handling of course
<gcampax> but gdm's pam handling is by far more complex than policykit's
 and it's tailored to gdm needs
<halfline> indeed it's more complex than policykit's
 but ultimately we'll want to be able to authenticate in the same ways for policykit requests as we do for login requests perhaps
 anyway, that suggestion is orthogonal to all the other discussions
 and we can perhaps unify things at a later date
* davidz likes to do the drive-by (sorry for the disruption)
<halfline> there's already a ton work in play
<gcampax> very true
<halfline> it is definitely a good idea though
 and one we should ultimately pursue
<gcampax> so it's now a matter of getting the accountsservice to store pins (btw, where?)
<halfline> i sort of alluded to something similiar on the mailing list thread a while back
<gcampax> and then write a small pam module to pull them out
<halfline> accountsservice stores per-user data in /var/lib/AccountsService/users/$USER
 none of the other data stored there is "secret" per se
 and that file is currently world readable
<halfline> so it may make sense to add a new file that's not world readable
 although i wonder if at this point it would make since to bring stefw in the conversation
 regarding the pam module, I would probably not use any of the standard prompt message types to get the pin
<gcampax> right - because one thing that we didn't consider is keyring unlocking - it essentially defats the point of a PIN if the first thing you ask for is the keyring password
<halfline> instead treat the pin entry as something that happens outside of the pam conversation, and the pam conversation just stalls until its finished
<gcampax> halfline: why so? at the greeter level, we know it's gdm-pin and not gdm-password or something else
<mclasen> gcampax: that is equally true for all alternative auth methods
<gcampax> and we can show the pin pad instead of the entry
<halfline> gcampax: because we're using a greeter specific mechanism, we don't need to tunnel through the pam api
<halfline> you could conceptually think of the pin entry as something happening elsewhere
 conceptually similar to the pin getting asked on your phone or osmething
<gcampax> yes, but using standard PAM is easier than setting up a private communication channel
<halfline> the fact that it's getting asked on screen is an implementation detail that I don't think should motivate how the module is implemented
<stefw> halfline: we should tie pin usage to use of a tpm module + key
 if you actually want the pin to be 'secure' and 'local'
 otherwise it's just a short password
 and why not use it as such?
<stefw> especially if policykit is going to start accepting these pins
<halfline> okay so you mean like a pkcs11 soft token ?
<stefw> no i mean the tpm module found in these new fangled tablets :)
 hardware
 so you create a key that is local to the machine, and can't be moved.
 but it could be used with a soft token during development as a proof of concept
<halfline> ohhh i see what you mean
<stefw> i guess we have to decide if these pins are supposed to be sorta like auto-login: "no real local security"
<halfline> well, certainly leveraging a hardware feature makes sense when available
<stefw> or if they're supposed to somehow protect the user's info
<halfline> but the "proof of concept" less secure way should work regardless
<stefw> well if the goal isn't security, then why not just encrypt the user's local password with the pin
<halfline> it's a conscious decision to be less secure for the benefit of easier access in a touch screen environment
<stefw> anything using the pin, decrypts the user's local password
 via a file, and then passes it through the pam stack
 and voila
 you have everything magically unlock correctly
<halfline> sounds good
<stefw> so don't do any pin handling in pam
 it's strictly outside of pam
 and also don't accept pins for policykit
 that's just broken
<gcampax> stefw: and where would you put that file?
<stefw> accountservice could manage the file
<halfline> so we'll aes encrypt the users password or so
 and decrypt it with the pin code
<davidz> stefw: well, the polkit authentication dialog should work exactly the same way as unlock and login authentication dialogs
<stefw> nah
<gcampax> if it's world-writable, you make password weaker because other users can brute-force the pin
<stefw> i don't think so
<davidz> stefw: why not?
<stefw> one is unlocking your screen
<halfline> and then set the PAM_AUTHTOK item before passing on to pam_unix
<stefw> davidz: and the other allows you to make changes to your system
 two different use cases
 pins are trivial to hack
<davidz> stefw: not really... both are used for simply proving that the user in front of the system really is the user
<halfline> gcampax: the file wouldn't be world-readable, accountsservice would do the actual checking i suppose
<davidz> stefw: pins may be trivial to hack...
<davidz> stefw: but if pins are good enough for gdm/screen-lock why are they not good enough for polkit?
<stefw> lets put it this way: when you have autologin, should policykit just never prompt for the user?
<davidz> stefw: (as a point of reference my iphone and ipad are protected by pins... if you get those devices and guess the pin, I'm screwed)
<gcampax> halfline: and would give the greeter back a password (or whatever is the result of decrypting the file)?
 or short-circuit to pam (ugh)?
<stefw> davidz: but you get asked for your apple account password too
<davidz> stefw: I would think polkit would never interrupt the user for the users _own_ credentials is autologin is enabled
<stefw> davidz: i disagree
 and so does mac os, windows and others
 even if you have autologin enabled, you should still be asked to prove that you know the password before making changes to the system.
<halfline> gcampax: hmm, that's a good point
<davidz> stefw: well, for those things you use polkit's auth_admin instead of auth_self, I think
<stefw> davidz: yes i am imiganing auth_admin
<davidz> stefw: even with user in group wheel, those should probably prompt the user to authentication even if autologged in
<stefw> i agree. with auth_admin, even if the current user is an admin, it should ask for just the pin or no prompt at all.
<stefw> halfline: could we make the pin thing a pam module?
<stefw> it accepts one AUTHTOK and reads the file diddles and then replaces with another AUTHTOK?
<halfline> stefw: it will definitely need to be a pam module
 but
 screensaver pam stack has traditionally run as the user
 although I guess that's maybe not going to be true anymore
<stefw> dumb question: how does the screensaver pam stack read /etc/shaddow
<halfline> now that we have gdm handling the unlock pam stack
<gcampax> halfline: that's no more, it goes through gdm (in gnome-shell, fallback mode is not ported)
<halfline> pam_unix ships a setuid helper binary
 called pam_chkpasswd
<stefw> ah
<halfline> err unix_chkpasswd
<walters> unix_chkpwd
<stefw> could pam_pin make a dbus call?
<halfline> whatever
 sure pam_pin could make a dbus call
 to accountsservice or whatever
<halfline> gcampax: okay so if the unlock stack is running as root now, the pam module could do the heavy lifting itself in theory
<stefw> yes that would be cleaner.
<gcampax> yes, that seems possible
<stefw> fwiw, passing the user's login password over dbus feels wrong, but if we define security as a non-goal for this PIN stuff, then i guess it's not the end of the world either.
<halfline> though, the question then is, where would it store it's encrypted file
<gcampax> stefw: it's not that, the problem is allowing normal users to ask accountsservice to decrypt
<halfline> right now, passwords go from the greeter to the pam backend through a private communication channel
 (using dbus peer-to-peer communication)
<stefw> gcampax: that's true
<stefw> trivial to brute
<halfline> certainly, the more segregated we can keep this code from the other code, the less chance there will be a CVE down the line
<stefw> so it's better if the only one who can do pam_pin is root
 halfline: PIN should be treated like auto-login from a security perspective
 unless we can actually make it secure using a tpm + pk
<halfline> doesn't mean there won't be a CVE
 just affects the impact level of the CVE
<stefw> right
<stefw> i'd suggest calling it pam_gnome_shell_pin or something like that.
<gcampax> so, summing up: pam_gnome_shell_pin module stacked before pam_unix
 takes the pin from PAM, passes it to accountsservice, gets back the password, places it in PAM_AUTHTOK and returns success
<halfline> right in a separate gdm-pin service file
 i think we decided it would be better
 to cut accountsservice out of hte loop
<stefw> right
 just have this be for pam stacks running as root only
 limit its scope to what we need
<gcampax> ah - i though the problem was just with going directly to accountsservice
<stefw> if we want to come around and do this properly later as a general purpose thing, then we can.
<gcampax> 'cause for actual storage having a daemon is useful
<halfline> so the pam module would operate on a file in /var/lib/gnome-shell-pin/something 
<halfline> gcampax: it's just from better if we can segregrate this code from everything else
<halfline> s/from//
 and we can do that now, without setuid binaries, because of your screensaver changes
<stefw> nice
<halfline> so we should leverage that
<gcampax> but what about writing?
 are we relying on pam_chkauthtok?
<halfline> that's a different stack the pam module would implement
<gcampax> (which is not used by accountsservice's SetPassword, btw)
<halfline> right
 whatever code set the pin
 user accounts dialog
 or initial-setup 
 or whatever
 hmm
<stefw> theoretically the writing *could* be handled by accountservice, if we want this to happen in both g-c-c and initial-setup
 or you can implement a 'password' call for this pin pam module
 if you really want to get it right :)
<halfline> i guess both is right
 the pam module should implement pam_sm_chauthtok or whatever
 but accountsservice should be the one doing pam_chauthtok
 i wonder how were doing ordinary password changes atm
* halfline looks
<gcampax> passwd for the logged in user, libshadow for everyone else
 (the latter via accountsservice)
<halfline> ewww
<mclasen> what did you expect ? 
<mclasen> I don't think you can do much better as long as pam sits in the middle
<gcampax> mclasen: you can run pam in accountsservice
<halfline> hmm
 so the point is
<gcampax> (and ensure that pam modules honor use_authtok)
<halfline> pam is gross
 and ideally we'd only have it implemented in one place
<halfline> but again
<mclasen> gcampax: I forget why, but that doesn't quite work the same as running passwd in the user session
<halfline> we have to keep the scope of this somewhat bounded
<stefw> running the pam passwd stuff in the user session prompts the user for the current password
 which is needed for the keyring
<gcampax> mclasen: it's still better than changing shadow directly, I'd say
<stefw> of course i'd be happy if someone waltzed in with a solution to that, but not so far :)
<halfline> i don't see any code changing /etc/shadow directly
 am i missing it ?
<gcampax> halfline: it runs usermod -p "password"
<halfline> oh and that edits /etc/shadow directly
* mclasen washes his hands off what usermod does
<halfline> anyway, ideally we'd funnel all this code through one daemon that manages pam
 be it policykit or some other daemon used by policykit and gdm
 but
 that's out of scope
 so for now, i'd say
 just add a new method to accountsservice for setting the pin
 and then have it do the pam conversation on its own
 but
 i would do this in a helper process
 not the accountsservice binary itself
 since loading pam modules into a process tends to muck with it
 another thing is, this whole pin feature, is sort of an independent chunk of the bigger work you're putting in
<halfline> and the bigger work is by far the more important work, so i would deprioritize the pin feature compared to other parts
<gcampax> uhm... ok
 but I'm happy we have a clear plan for it
<halfline> one other point i fogot to mention is the SSSD folks have expressed interest in being the central pam daemon before