#4510 [RFE] Allow and manage multiple passwords (ideally, full 'application specific password' model)
Opened 9 years ago by adamwill. Modified a year ago

FreeIPA does not currently allow users to have more than one password. This would be desirable functionality.

There are many possible use cases for it. Several fall under a category that could be broadly defined as 'application specific passwords' (as Google refers to it), or possibly 'partially trusted credentials', or something.

For instance: I have my mail server configured to use FreeIPA authentication via PAM. I have three computers, two phones and a tablet configured to use my email server with my user ID and password. Then the tablet gets stolen.

Now I have to change the single password on my account, and re-configure all systems that authenticate to anything using that password to use the new one, including all five other mail client apps.

If I could create multiple passwords, I could create one for each of the devices I want to use as an email client. If the device is then stolen or I feel I can no longer be sure its credentials are secure for any other reason - say, I just logged in over an unsecured hotel wifi network, or something - I can revoke or change just its password, without needing to revoke or change the others.

Ideally, this model could be quite sophisticated, and allow you to configure access based on the password used to log into an account - if I log in with the 'master' password (or, even better, the master 2FA token!) I get full access to the account, including changing all the other passwords and access to all services, but if I log in with an application specific password, I can only access a particular subset of systems and services that password is allowed access to (e.g., it could grant access only to log in to the mail server).

That's probably rather more work though, as it'd need UI work and probably an adjustment or at least an extension to how access policies are managed. Just simply allowing multiple passwords per account would be a good start (and maybe a very limited form of 'access control' could be done by only allowing the subsidiary/secondary/application-specific/whatever passwords to be configured after log in with the 'master' password).


This assumes that you same your password in the device, right?
So what if instead you use a password (even if you cache it) and a token like Yubikey NEO. Then you get two factor authentication into your devices, SSO with Kerberized services and if the device is lost the password is not that important as it is just a single factor.
I have a video of the prototype. I am having trouble making available. As soon as I can I will attach the link.
What you are suggesting is generally not a good practice and would require quite a lot of work.

Well. That's a completely different approach to the problem, and I wasn't really looking for suggestions as to how to set up my network, I was suggesting a useful feature. The example was just one example; there are enough others that it didn't seem worth beating that particular dead horse too hard. (Webapps is one obvious one). Yubikey Neo doesn't work on all mobile devices, for instance - I've got a Firefox OS phone sitting right here.

"and if the device is lost the password is not that important as it is just a single factor" <---- that's a rather large handwave you just made. The whole point of 2FA is that it's two Factor Authentication. If you're going to consider the password more or less public, you're then back to 1FA.

We kicked this around in #freeipa on Freenode this morning and devs there seemed interested in the idea and explicitly suggested I file a ticket if there wasn't one already, so I did.

Sure. I am just not sure that it is the right solution for the problem. And I want to understand the real problem. So far I do not like the example as it sounds like a bad practice. Can you share other examples where it can be useful?

As I think of it the RFE generally calls for a group account (whether it is used by a single person or many people is really up to the policies though it is definitely an opportunity for it to be abused).

So effectively suppose you have a special account "X" and then there are 10 people that have to log with this account for whatever reasons. Instead of logging with their own account (which would be the right thing to do from the audit perspective) they log with the same account but at least with different passwords.
This is sort of better than sharing the same password but unclear why separate accounts can't be used.

I am not against an RFE I am just trying to find some practical reasons that would be common for many deployments. Your input is definitely welcome.

"but unclear why separate accounts can't be used"

well, because as far as the service you're authenticating to is concerned they're not separate accounts. I want all my mail clients to auth to the same mail account, obviously. It really is just one account, so far as the service is concerned.

I don't think the mail case is a particularly bad example, really. I'm currently drowning in Yubikey Neo docs and while it seems like you could possibly use it in the way you describe, I'm not entirely sure and I'm not exactly going to go out and drop $50 on a single one just to find out. Of course, in the example above you'd need three of 'em, so that's $150 on hardware. You'd also have to have supported phones and tablets, of which there aren't very many - neither of my cellphones is supported, and my tablet doesn't have NFC at all. Even assuming it worked, I'm assuming you'd wind up going through the dance of typing your password and tapping the Neo fairly often - probably every time you started the phone, or came out of a moderately long sleep - which would get old in something of a hurry.

The 'app specific password' approach involves a hardware outlay of $0 and no re-entry of passwords until you change it. It's not quite as secure as a proper 2FA approach, no, but surely you can agree it's better than every device sharing the same password you also type interactively any time you log in anywhere? (Another benefit of this approach is it would make it less inconvenient to change the 'master' password, which would be used for interactive logins, as you don't then have to change the same password stored in all your devices every time you do it).

Good points. Thanks for clarification. I am trying to figure out ho to download and convert the demo but no success yet. Please do not waste you time and money on NEO until you see the clip.

The email access seems like a good example though it might be easier to have 10 different login accounts be mapped to a single mail account than to have 10 passwords on the same account. We will see what makes sense depending on other use cases. Please bring more.

OK, managed to extract it. Here it is: https://drive.google.com/file/d/0B3tfpNCVjJdCWjQ3dGNHeEcwaDQ/edit?usp=sharing

Here is what happened:
- User starts authentication application
- To use Android Kerberos with OTP, an Kerberos armor for FAST tunnel is needed, so the device needs to be registered.
- Server pre-register a host principal, and send necessary information for registration to client via QR code.
- Client scans QR code then joins IPA realm.
- User enters user name and his PIN (can be cached by the app), as well as OTP
- Application using Kerberos library talks to Kerberos proxy over HTTP(s) - this proxy is just checked in couple months ago into the MIT 1.13 tree upstream
- Kerberos proxy passes Kerberos authentication request to KDC
- KDC forwards OTP data to external authentication server over RADIUS - Yubikey server in this case
- Server responds with success (or failure)
- KDC creates a so called ticket granting ticket – TGT and sends it back to proxy via Kerberos protocol
- Kerberos proxy wraps traffic into HTTP(s) traffic and replies to the authentication app
- App sticks ticket into the ticket cache
- App optionally unlocks access to other enterprise applications by scanning QR code (QR code contains URLs and server principal information as well as icon)

I know this is not exactly what you have been looking for but this is so far what we were thinking regarding the mobile security.

To me it sounds like you want application specific extensions to FreeIPA.
Isn't this something you can solve with adding custom schema to hold a password hash that the application will check directly ?

Simo, ab pointed out to me that the IPA pwd plugin will validate against all values in userPassword so multiple passwords are supported today. There is just no means of managing multiple passwords right now.

AIUI he wants a client-agnostic way of handling multiple passwords as he has no control over the client.

simo: think of me as a dumb user demanding a shiny feature ;) Yes I can hack this up somehow, in fact I already have - you can do it at the application level, i.e. in the mail server. See https://www.happyassassin.net/2014/08/26/adding-application-specific-passwords-to-dovecot-when-using-system-user-accounts/ . It just occurred to me while I was fiddling with dovecot configuration and hand-editing the hashed passwords into a passwd file that, hey, wouldn't it be nice if my identity / authentication server handled this instead, and had a nice shiny interface and/or a one-step CLI command? :)

dpal: If more specific use cases occur to me I'll mention them, someone on IRC mentioned questionably-trustable webapps when I brought up the topic. Thanks for the details on Neo/Kerberos - I actually assumed Kerberos would be too much to ask for and just looked at it from the angle of how possible it would be to get an OTP into a mail client (I use K9) for auth. Of course, even assuming you get Kerberos authentication / ticket issuing working, you need an email app that auths via GSSAPI; my mail app, K9, which I think is one of the more popular ones, only offers PLAIN and CRAM_MD5 auth.

dpal: forgot to mention - "though it might be easier to have 10 different login accounts be mapped to a single mail account than to have 10 passwords on the same account" - well, I mean, that's actually exactly what I have now, that's the trick used to do app-specific passwords at the dovecot level. The 'login accounts' only exist at all as far as dovecot is concerned, they're specified in a passwd-style file read by dovecot, and each one has a parameter which tells dovecot to remap it to the account I want to log in to (changing the username during auth is a trick dovecot explicitly supports).

To me, though, that feels like the cute nonsense hack, it seems a bit messy. Is it possible to remap login accounts to mail accounts at FreeIPA level? I don't see how that would work? If not, then you're back to doing finicky auth configuration tricks at app level, and stop me if I'm wrong, but I kind of got the idea that FreeIPA was about saving you from having to do that kind of thing.

I'm not even sure if I could have created the login accounts in FreeIPA and then just done the login->mail account mapping at dovecot level. I'm not sure if you can use the passwd-file trick partly, using it to do the username remapping but sending actual authentication through PAM/NSS; it may work if you use PAM as the 'passdb' driver and passwd-file as the 'userdb' driver, but I haven't tried.

Well... IPA definitely sets the goal of making things easier to manage. I get the use case. I agree that there is one. I also agree that what you mention above is a hack but it sort of works now. Ugly but works. There are so many things that FreeIPA needs to solve that do not have workarounds. I am not saying we would not do this ticket, we probable would, the question is how soon we will be able to turn to addressing this use case in the presence of an ugly but workaround in comparison to other quite pressing issues we have to look into now.

Right. Today, we decided to accept this RFE as a valid use case, adding to respective milestone. We do not have capacity ourselves to look at it in the earliest releases, any contribution counts.

Metadata Update from @adamwill:
- Issue assigned to someone
- Issue set to the milestone: Future Releases

7 years ago

Metadata Update from @pvoborni:
- Issue assigned to rkalinec (was: someone)
- Issue close_status updated to: None

4 years ago

I guess these days to keep up with fashion we should make them longer and server-generated and call them "API keys"...:P

Login to comment on this ticket.

Metadata