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