Re: gnome-keyring keyring brainstorm

[Stef Walter <stef-list memberwebs com>]

Sorry for taking so long to continue this discussion...

Michael Leupold wrote:
> It's the what konqueror uses for storing form data on web pages, probably 
> mostly because putting all non-secret fields' names and values into the item 
> name (KWallet doesn't provide attributes, just one name) makes it look strange 
> when editing :) Most other applications just use a secret string. With those 
> KWallet operates pretty similar to keyring. Item names (= mangled attributes) 
> are stored as hashes for searching as well as in the secret part.

Interesting. So I guess we can continue this state of affairs. Since
KWallet already stores everything as a secret, then it can continue to
store stuff in the secret, am I right?

Attributes in gnome-keyring are specifically used to find a secret.
These are not secured. The hashing of these (in gnome-keyring) is a not
for security in any way, it's a performance boost.

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...

>> FWIW, it's worth noting that in most protocols the user name is not (and
>> is not treated as) part of the secret.
> 
> Yes, but taking this possibility away from people who are used to it will 
> still be perceived as a loss of security, no matter what. :)

Yup, and I think we can meet that goal, by making 'secret' things go in
the secret.

> Partly, yes. At least that's how I stumbled upon the bug. For all KDE 
> applications I can however adjust the timeout because they're using an API 
> wrapping the DBus calls instead of calling DBus directly.
> 
> I remember the following things that were inconvenient to implement:
> - The client API has to be adapted to take care of timeouts. Care has to be 
> taken wether to react the same as for a failed Unlock (doing it will relieve 
> relieve clients using the API of handling the timeout).

True, good idea.

> - The dialog asking for the password has to disappear on timeout
> - .. but there might be other queued (not-yet-timeout) requests waiting for 
> the Unlock to finish which need the dialog

Yes, good to keep in mind.

> - There might have been an issue with detecting the timeout on the server-side 
> but that might have been qt-specific (I just don't remember exactly)
> 
> Overall manageable, but it adds extra complexity that has to be taken into 
> account. 

But do you agree that the complexity is less than designing another
layer of operations handles + async calls into our API?

> I think the easiest way of implementing it (without the asynchronous 
> stuff I mentioned earlier) would be to not handle timeouts in a special way 
> (timeout = failed unlock, eg. too many failed password events) and setting the 
> timeout to INT_MAX. Then we can poke the DBus people for no-timeout 
> send_with_reply :)

Yup, good call.

> 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.

> (2) multiple methods to unlock a collection:
> I think it would be awesome if we could provide a way to unlock a keyring not 
> only using a password but also using a smartcard (and possibly even 
> biometrics) - if possible several authentication methods on the same keyring. 
> This would however require the format to be changed as well.

Not sure how KWallet works, but most of these methods don't work with
gnome-keyring at all. We're not doing 'authentication' when we're
prompting for a password, we're actually unlocking something. The
password that the user types actually decrypts the keyring data. [1]

I'm glad were moving forward on all this. Should we put this API up on a
wiki somewhere and start finalizing it?

Cheers,

Stef

[1] http://live.gnome.org/GnomeKeyring/StoringSecrets