← Back to team overview

ubuntu-phone team mailing list archive

Re: [Development] Solution for a password/secret storage

 

On 13-03-19 03:22 AM, Alberto Mardegan wrote:
> On 03/18/2013 05:01 PM, Bruno Girin wrote:
>> Not all devices will have a SIM, tablets in particular may not. And
>> looking forward to 14.04, I assume we'd want this code to be re-usable
>> on the desktop (or server even)?
> 
> Might be a good idea, though I'm not thinking of that yet. Sure, I think
> we shouldn't make any assumptions that might prevent us from putting the
> same service in the desktop if we decide to, but for the time being I
> think that the GNOME keyring is doing a very good job.
> 
>> Having said that, maybe there is a case
>> for allowing different backends with the default being an encrypted
>> store on the device. An alternative backend that would use the SIM could
>> be good as an option as long as it doesn't make it difficult for the
>> user: say I got tired of Voodoophone and wanted to switch provider to
>> Nothing Nowhere, I'd want it to be painless and not lose all my saved
>> passwords because I changed the SIM.
> 
> Indeed. What signond supports now is a plugin system for different key
> providers and defines an interface for them:
> 
> http://code.google.com/p/accounts-sso/source/browse/lib/signond/SignOn/abstract-key-manager.h?repo=signond
> 
> By using LUKS (or even encfs, with some tricks), it's possible to
> associate more than one key to an encrypted partition: that is, there
> might be multiple keys which allow unlocking the secrets DB: a SIM card,
> a password, a lock code, a fingerprint signature, etc.

I would really hate having a system that relies on mounting an encrypted
filesystem. It seems to me there are way too many disadvantages to this
to be worthwhile.


> 
> In particular, we would not be restricted to a single SIM: we can easily
> think of a way to authorize a second SIM, for instance:
> 
> - user removes current SIM
> - a dialog appears explaining that if we wants to authorize a new SIM,
> the user has to insert it while the dialog is still open -- otherwise,
> dismiss the dialog
> - user inserts the new SIM

I think this is way too complicated for a user to understand. I'd hate
for users to lose all their secrets just because they didn't understand
what they were doing.

> 
>> Should that be integrated with the PAM architecture so that different
>> keyrings (or collections as called in the freedesktop API) can require
>> different authentication methods?
> 
> Our service could be a PAM provider, but I don't think it can use PAM as
> a client: AFAIK, the PAM API only allows you to know if the user has
> authenticated, but it doesn't let you retrieve the password/token used
> to authenticate (and which we could use as key for the encrypted storage).

Yes, a PAM module can retrieve the password.

Marc.




Follow ups

References