Re: Do you use multiple gnome-keyring keyrings?
- From: Nate Nielsen <nielsen-list memberwebs com>
- To: Jon Nettleton <jon nettleton gmail com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Do you use multiple gnome-keyring keyrings?
- Date: Tue, 17 Apr 2007 04:43:16 +0000 (UTC)
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]