Large hole in KWallet?

Mik Mifflin uzimonkey at gmail.com
Mon Aug 8 15:47:46 CEST 2005


I was messing around with KWallet, and I was shocked to see that the 
list of programs that can access a wallet without confirmation are 
stored in cleartext.  If a malicious program can easily add itself to 
this list, wait for the user to open the wallet and surreptitiously 
gain access to the entire password database, there's not much point to 
even encrypting the data.  Since an attacker can add any program name 
to this list he likes, or see the programs that are already there, he 
can disguise himself as one of these programs and gain access to the 
passwords. 

KWallet should: 
 * Store the list of programs that can use the wallet without 
confirmation in the wallet itself.  This prevents people from easily 
modifying or reading it. 

 * Confirmation dialogs should be on a per-key or per-folder basis,
not a per-wallet basis.  Kopete has no business accessing kmail's
passwords.  Exploiting the DCOP trust would be much less serious this
way.

 * Applications should maintain tighter control of the wallet.  If an 
IM application needs passwords to log in, should it keep the wallet 
open until it closes?  I'm imagining a "Keep wallet open" option in 
programs that will possibly need it again in the near future maybe? 
There's no point in keeping it open until the program closes. 

I think this issue is pretty important.  Users store all kinds of 
passwords in kwallet, everything from IM to web accounts.  People also 
have a reputation for taking shortcuts when it comes to passwords, like 
using one password for 10 different accounts.  Using KWallet is a bit 
dangerous, storing the passwords anywhere is, but I think it could be 
improved greatly by implementing these changes. 

KWallet will never be 100%, but it could be a lot better than it is 
now. 

https://www.bsrf.org.uk/article.php?story=20050808095252412

-- 
 - Mik Mifflin


More information about the kde-quality mailing list