Re: Do you use multiple gnome-keyring keyrings?



Jon Nettleton wrote:
> The above approach also gives you the ability to have different
> passphrases for different certs, or services.  They are retrievable if
> you forget them but remember your system passphrase.  It also gives you
> only one passphrase (the one to unlock the Login keyring) to keep in
> sync with your system passphrase.  So if something happens and they get
> out of sync you don't have to update 20 different passwords to get
> things back sync'd up and unlocking on login properly.

Cool idea. It's a good solution to multiple keyrings, unlock on login,
and things like key store integration. It also helps users with simple
needs keep things simple, while security minded users can have
uncompromising security.

But I have a few suggestions to help simplify things slightly...

 A. Let's not expose the 'Login' keyring as a normal keyring. I don't
    think other applications should be allowed to mess with it. We
    might consider it a  implementation detail internal to
    gnome-keyring-daemon. For simplicity we might call it something
    like 'master passwords' in the code.

 B. Any keyring, key store, etc. that has a valid password configured
    in the 'master passwords' would be unlocked upon login.

 C. When the user changes the password to their keyring, they'd have
    the option to choose whether it gets unlocked upon login or not.
    In effect they'd be choosing whether the keyring password would
    be stored in the 'master passwords' or not.

 D. Initially the first default keyring for a new account would be
    encrypted in the same password as the login password (ie: and
    the same as 'master passwords' is encrypted in). This allows
    people who absent mindedly move keyrings or certificates to a
    different system to use a password they know to access them.

You've obviously thought about this a lot, so there may be things I'm
missing in my suggestions above. But I think that implementing it in
this way would simplify things for both users and developers.

Cheers,
Nate Nielsen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]