[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Storing passwords
From:       George Staikos <staikos () kde ! org>
Date:       2003-04-29 20:57:55
[Download RAW message or body]

On Tuesday 29 April 2003 16:27, Anthony J Moulen wrote:
> You are correct, it doesn't make sense for a single application.  It has to
> be across the board, multiple applications. Then when I log in at the
> beginning of a session I should be prompted for my "kwallet" password to
> decode my password store.  Then all "kwallet" aware applications can query
> it to get a password for a specific service.  If the password isn't there
> it is prompted for in a standard way and returned to my "kwallet" unless I
> uncheck the box saying I don't want it to manage this service (default mode
> could be either checked or unchecked, doesn't really matter as long as it

    That's basically the idea.  I would like to have separate stores for 
different types of data though.  The idea is to have several standard 
KDE-wide wallets, and then allow applications to create their own as well.  
For instance, there could be a "network passwords" wallet, a form data 
wallet, and a "local passwords" wallet to start.  This way the user doesn't 
need to unlock his passwords to get form data.

   There will be a tray icon and GUI to manage this, so the user can relock 
the wallet at any time to prevent further applications from using it.

> is consistent). Kwallet should then use a fairly standard tool for storage
> like libgringotts or something along those lines that can be updated on a
> regular basis without updating kwallet as long as the underlying library
> stays compat.

   I had a look at that but I don't see much of a benefit in it.  It adds a 
whole lot of code that we won't use, 3 external libraries at least, and I 
don't particularily like the API.  All we really need is a small subset of 
what is in there anyways, and I can easily code this.  Most of it is already 
done, and it just needs to be fixed up and properly integrated.

> Now there also have to be a way to limit the applications that shouldn't
> have access to the passwords from querying them.  Probably an md5sum check
> against the binary calling the service and the one that stored the info. 
> If the binary has changed don't return the password string.  A better

   I think this is a lost cause.  There is no sane way to protect against 
this, and if you're worried about some rogue application getting passwords, 
you should also be worried about it intercepting your traffic before it is 
even encrypted.

> solution would be to stop each application from sending the password and
> use the wallet itself to send the password to the other side, but this
> would require all network streams to be io streams that could be passed
> around.  Not a bad model really but a lot of work to change the
> environment.  And it would mean that the wallet would have to be pluggable
> so that each application could attach its authentication methodology onto
> the wallet and then just call its model and key to send the auth info to
> the other side of the stream.

   What is to stop any application from plugging in then?  I think this gains 
nothing.

   The best that can be hoped for is to optionally prompt the user whenever a 
wallet request comes in and ask if it should be accepted and fulfilled.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]