[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-30 20:11:07
[Download RAW message or body]

Judiciously Snipped to cut down on your mailbox size ;-). 

On Tuesday 29 April 2003 04:57 pm, George Staikos wrote:
>     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.

This would be interesting, I would think that it would be a kde wallet manger 
which manages sub wallets.  Any app which belongs to a wallet class would be 
shared.  Apps with special concerns could then require a special class onto 
themselves.  The manager would allow you to group classes under a single 
unlock function.  So I could do email, fish and kdesu passwords all with one 
password.  I also like the relock concept, so while I could unlock multiple 
classes at once, I could go back and lock any one after unlocking them.  
Should also be allowed for a single password, or per-class password. 

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

You are probably right here.  The only advantage I could think would be cross 
desktop usage.  But I would think that worrying about KDE first would be more 
important, if you have a refined enough API it should be good enough.

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

I don't know about this being my concern, my main concern is that only 
services run by the same user would be able to connect to that password 
store.  The problem is under Linux and probably all UNIX variants, there is 
no login level id.  So your id is the same on the first login or the 100th 
login.  So if someone were able to come in as you, they could start a process 
to pull your passwords from your wallet.  This would be of greater concern to 
me then them simply running the same application and having the application 
use my wallet.  

As to the communication, it could be encrypted via the use of a rotating key, 
the application would pick a key using a "wallet_encrypt" api,  it would then 
use the wallet public key to encrypt its key.  The wallet woudl then decrypt 
the key on its end.  All communication to the application would be using the 
applications public key for that session, all communication with the wallet 
would use the wallet public key.  This key would be generated once, and would 
have to be decrypted on the wallet end by the user's password to the wallet 
manager.  What this does is allows for network abstraction of the wallet 
manager.  You could thus have a central wallet manager and have applications 
call it and encrypted the communication between each other.  Not that I would 
ever want to go this far with it myself but it could be interesting to walk 
up to a system, have a kwallet login screen, unlock your wallet on the wallet 
server, and be able to do all your connections with single signon.  Would 
make kiosk operations very cool.  


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

This wouldn't stop any application from plugging in, what it would do is make 
it so that a password which was stored to say login to 
mail.joesmailserver.com, would only be used for that purpose.  So any local 
app would be able to use the stream, but wouldn't be able to get the 
password.  Which means they have to keep coming to an unlocked wallet to 
steal a stream.  And if the pluggin owner made a key which the application 
knew about (ie was compiled into both binaries) then you would be able to 
restrict it to just the binary that owns the plugin.  Consider it like the 
ssh keys in a way, they are generated at first run, these would be generated 
at compile time and internalized into both binaries.  The problem would be 
that you would have to retype your password when the application was updated, 
but you could still get in and review your passwords if you unlock the store.   
And a well designed GUI could allow for migrating passwords between 
application versions or builds. 

But I am sure you have put a lot more thought into this than I have.  I am 
just spouting off what I would like to see.  And if I knew how to code 
something so powerful what I would strive for.  From a security prospective, 
without binary keys in each binary, which are signed by the wallet as the 
signing authority on a box, there is no way to ensure full security of the 
wallet.  It will always be vulnerable to local attacks if you can gain 
priveledges of the user. This is about the only place windows has an 
advantage, because it is a single user environment, you can make some 
assumptions about the security of the individual id that you just can't make 
in UNIX.  Not that I am saying Windows is a good model, just that a single 
user system has certain advantages as well as disadvantages. 


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]