Re: gnome-keyring keyring brainstorm

[Stef Walter <stef-list memberwebs com>]

Michael Leupold wrote:
> Yeah, I agree. Most programs will only need the password stored
> secretly anyway because they'll have parts of the fields stored in
> their config (eg. mail/im accounts). If an application needs to store
> multiple secrets we could very well use a string to do so. It would be
> great if we could have that in the spec instead of applications/client
> libraries doing their own marshalling because like that we'd have
> better cross-desktop compatibility (imagine a kde application's
> secrets showing up as gibberish in the gnome keyring management
> application or vice versa).

Not necessarily. The "desktop file" format (the equivalent of GKeyFile
in KDE) could be used to have user readable "map secrets (string->string)".

>> It'd be a big bunch of snake oil to hash individually them for security
>> reasons :) Even if we did use a crypto strength hash algorithm, the
>> values are far too small, far too repetitive, and it's trivial to brute
>> the guessed values, as well as use them for rainbow tables etc...
> 
> Yeah, I agree. I think it is acceptable if it stays like this (afaik
> fields are hashed and stored secretly for retrieval at the same time,
> right?).

Yes, in gnome-keyring that's the case. However it doesn't have to be. In
any case I think this is an implementation detail and shouldn't be
mandated by the interface.

>>> I finally came up with two other things I had been wanting to implement for
>>> KWallet:
>>>
>>> (1) syncing collections (aim: multiple PCs):
>>> As keyring already provides mtime this should be a matter of providing a GUI
>>> for it.
>> True, that makes mtime a first class citizen. I was thinking of
>> relegating it to an additional desktop specific interface. But this
>> shows that we should include this in the main API.
> 
> I wonder how much is actually left for the non-main API. It sounds
> like we fitted almost everything into it already in which case it
> might make sense to have only 1 API.

One idea would be to implement things like specific unlock methods as an
additional interface, which may be supported by one or another daemon
but not specified in the main API.

As spec'd out, the current API has an unlock method that takes no
arguments. It expects the daemon to prompt the user or take relevant
action.

Put another way, the method of locking the 'collections' is completely
unspecified. There's Lock and Unlock method and a property for checking
the lock state, etc... Gnome keyring would initially have another
interface (implementation specific) which can be used to set passwords
on the collections.

It could be that some implementation of the API will store the the data
straight to a smart card, or some other form of secure storage.

Or another case is the multiple master password case which KWallet
supports that you described. A good idea by the way.

> Yeah, good idea. I've already been asking for modalities and we can
> just use the fd.o wiki to put the draft there. As soon as we have put
> something halfway final together we can ask for even more input (I'm
> sure other KDE developers would like to have a peek on it - otherwise
> they might feel like something's being forced down their throats, not
> sure about Gnome devs).

Yup for sure. Although suprisingly few people care about security
features, I'm sure many will care about any API changes or semantic changes.

Cheers,

Stef