Fwd: KWallet weaknesses (was: [PATCH] Make pinentry-qt read and store passphrases in KDE 3.2's wallet)

[Dirk Mueller]

On Thursday 04 December 2003 23:21, Ingo Klöcker wrote:

> the following is a short comment from Werner Koch (author of GnuPG) on
> KWallet. A flaw in KWallet is much more serious than a flaw in any
> other KDE program. So we really have to make extra sure that there's no
> flaw in KWallet's crypto code that could cause the data it's supposed
> to protect to be compromised.

Great reasoning, but was it necessary to make it public before the affected 
parties were able to investigate the claims and potentially provide a fix? 

>  * No intialization vector used in CBC mode -> FATAL problem.

As far as I know, KWallet *does* have an initialisation vector for each 
folder. 

>  * Passphrase to key conversion is not one of the standards like
>    pkcs#5 or the OpenPGK S2K method.  Instead a simple brute force
>    thing is tried by repeating the hashing the hash 2000 times.  I
>    also found no salt!

Thats indeed a problem. However, I doubt that anyone would actually go the way 
of trying to brute force the wallet. Its *much* easier to just steal the 
unencrypted data while the wallet is unlocked. 

As far as I can see, this was not covered by Werner's analysis. 

>  * The protocol used is not decribed.

It is described in George's slides which he presented at N7y. We also refined 
the storage protocol during this session a bit. I agree it might be better to 
put that along the source code in CVS. 

>  * The plaintext files seems to be filled with random during
>    initalization.  I can't see a reason for this.  This won't replace
>    an IV.

I think thats a misinterpretation of the code. 

> Kwallet as it stands now seems to be a major security problem.  

Well, anything that maps n passwords for n > 1 to the safety of one master 
password is by definition a security problem. There is nothing to discuss 
about that, no matter how clever you design your wallet. 

Maybe we should add a disclaimer like "Don't put the authorisation codes 
required to launch nuclear weapons into a kwallet. " up when the kwallet is 
used for the first time. 

However, kwallet has a reason for existence: its extremely nice for 
more-or-less throwaway web-accounts. there are dozens of places where you 
have to enter one password or the other for some kind of authorisation, like 
mailman interfaces, nonpublic webpages etc. 

Evidence shows that the plethora of places you can only access with a password 
increases drastically. Users cope with this in two ways: a) they use the same 
throwaway password for all accounts. b) they deduct the password from the 
login page itself. like repeating a word that is shown on the login page, or 
some part of the domain/url, possibly slightly altered with a tiny algorithm. 

comparing with these two very common strategies, kwallet is like a 10 meter 
thick stainless steel dugout. 

That said, I think its a much bigger security problem that KMail stores POP3 
and IMAP passwords essentially unencrypted in its configuration file rather 
than using a kwallet for it. 

I tried to talk George into providing different access levels, or passwords 
for each kwallet folder (a folder for webaccounts, a folder for mail accounts 
and a folder for private data like your credit card number or similiar), but 
for some reason we decided against this. Can't actually remember anymore why. 

> might be wise to tell George to read Peter Gutmann's recent papers on
> the deficiencies of various VPN protocols.

I fail to see how they affec the wallet. What do you gain by adding protection 
against insertion or replay attacks? KWallet is not "talked over the wire".