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

[Ingo Klöcker]

On Friday 05 December 2003 17:15, Dirk Mueller wrote:
> 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?

Werner sent his message to the public gpa-dev mailing list. So it was 
already public.

> >  * 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 usual, that depends on the threat model. So against which threats 
does the wallet protect the user's data? It protects the data against 
people who have access to the user's data but who can't install a 
trojan to get the data. The most common case is the theft of a laptop. 
In this case the wallet isn't unlocked and therefore the attacker will 
have to attempt an dictionary attack (and if this fails a brute force 
attack) on the wallet.

In which threat model is the wallet unlocked? If the attacker can run 
arbitrary code as the user? Well, sure, but the wallet can't protect 
anything against an attacker with this power.

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

The problem is that people won't just store unimportant data in the 
wallet. No, they will also store highly sensitive passwords in the 
wallet. Why? Because they don't know better.

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

Which isn't the worst idea if it's only used for unimportant stuff.

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

a) Not by default.
b) I'm sorry that I didn't have the time to add proper KWallet 
integration for KDE 3.2, but that's pretty much irrelevant given the 
fact that KMail already does what it does since it's infancy. So it's 
not as if we had made KMail less secure.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031206/19a76b04/attachment.sig>