[Authentication] project ideas

[Stef Walter]

On 2010-02-24 15:03, Michael Leupold wrote:
> Am Mittwoch, 24. Februar 2010 03:20:59 schrieb Ben Kibbey:
>> This way I only need to update the "isp" data for all applications that
>> use it. If there is a way to have the Secrets Service do this that would
>> be cool.
> 
> The concept used in the Secret Service API is a bit different but can in some 
> ways achieve similar things. Secret items in the API are usually not stored 
> and retrieved by name ("isp", "exim", ...) but by attributes. This basically 
> means that you wouldn't store an imap account's password using the name "isp" 
> as its identifier but would attach attributes likes 
> "server=imap.myisp.com:993" or "type=email" which would enable the item to be 
> found by several applications.

Right on, and as many attributes can be used as necessary to uniquely
identify an item.

>> It would be cool to see gconfd (not sure what KDE uses for configuration
>> management) and the Secrets Service merged into the same server.  Maybe
>> a flag in a configuration data that requires the client to authenticate
>> before retrieving it.
> 
> There's already some (afaik non-public) KDE API for storing secrets using the 
> current KWallet through the means of the KConfig system. I don't believe 
> merging configuration and storage of secrets is that good an idea. I'd like to 
> keep the two separated. Especially since I fear the result might get so 
> complicated we might face a problem finding someone to maintain it - after all 
> configuration systems and password management daemons don't seem to be among 
> the top 10 "projects I'd like to maintain".

I agree with Michael, this would be very complex and tough to secure.

Because the current secret service supports as many 'keys' or lookup
attributes as required, it is easily paired with any configuration
system. One stores the sensitive parts of the configuration in the
secret service, and the rest in whatever config daemon the application uses.

Another approach is to store a random string in the secret service, and
use that to encrypt a string before sending it to gconf or KConfig. This
is something I'd like to facilitate in a future secret service client
library.

I realize in an ideal world it would be nice to just mark some things as
'secret' and have them be magically stored securely. It seems to me that
doing so would be really tough to get right. I prefer each component
excelling at what it does best (config, secrets) and using them together
in a 'unixy' manner.

>> Also require as few dependencies as possible. Nothing GUI related since
>> this may bloat non-GUI related apps.

FWIW, the secret service is an API which will have multiple
implementations such as KWallet and gnome-keyring, and maybe more.

>> Just some ideas. I hope the Secrets Service can use some of them.  You
>> can find pwmd at http://bjk.sourceforge.net/pwmd/.
> 
> Yeah, fresh ideas are always welcome.

Yes, thanks for joining in!

Cheers,

Stef