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

List:       kde-devel
Subject:    Re: Re KWallet
From:       George Staikos <staikos () kde ! org>
Date:       2004-05-05 15:47:10
Message-ID: 200405051147.11085.staikos () kde ! org
[Download RAW message or body]

On Wednesday 05 May 2004 10:29, Michael Buesch wrote:
> > I'm sure many other people have given the code an examination by now
> > seeing as how it is in kdelibs.  Honestly, I would suggest that a KWallet
> > is vastly more likely to be broken by a bad password than an
> > implementation flaw. Remember that no matter what algorithm you use, a
> > dictionary attack will defeat a bad password.
>
> Passwords get delivered through the DCOP interface.
> So I think this is the only "weak" point for security in
> KWallet. But, is it really a big problem? I say no.
>
> So, George.
> I had an idea yesterday and I don't know if it is already
> discussed, thus I will ask here.
> What about (optionally) encrypting all critical data in the
> backend, then sending it over DCOP and transparently decrypting
> it in the KWallet client lib?
> The application will never see if it was encrypted or not, since
> it's already decrypted when it receives it, always.

   How do you intend to do authentication, prevent man-in-the-middle, and 
fwiw, how is this safer when an attacker who can read the ICE socket can 
probably also read the application or kded memory?  If we move the decryption 
into each app, then we can't share the master password, each app has to 
"know" the master password, and synchronization becomes very complex.

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