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

List:       kde-devel
Subject:    Re: Storing passwords
From:       Anthony J Moulen <ajmoulen () moulen ! org>
Date:       2003-04-29 20:27:27
[Download RAW message or body]

On Monday 28 April 2003 10:19 am, Kuba Ober wrote:
> On piątek 25 kwiecień 2003 07:29 pm, Unai Garro Arrazola wrote:
> > >no need to, just make sure the file where the passwd will go to be only
> > >read/writeable by the user, i.e., perms like 0600. check out kppp's code
> > > for an example on how to achieve this.
> >
> > Thanks for the idea, changing the permissions would do to keep it safe
> > from others, but still, I think it's a good idea to encrypt the password.
>
> You are requesting something that doesn't make sense :)
>
> If you encrypt the password, you need another password/key to decrypt it.
> Either your program will have that key fixed insode of it (as kmail does),
> then it's only obfuscation that provides no real security, or you will have
> to enter it each time, where a kwallet-type arrangement is much better.
>
> Cheers, Kuba Ober
>
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 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.  

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

As for Kwallet itself, I haven't heard anything about it till here this last 
week, sounds interesting.

- Anthony

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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