Re: The situation of KWallet, and what to do about it?
- Date: Fri, 15 Jul 2016 10:22:32 +0200
- From: Elvis Angelaccio <elvis.angelaccio@xxxxxxxxxxx>
- Subject: Re: The situation of KWallet, and what to do about it?
2016-07-14 1:11 GMT+02:00 Albert Astals Cid <aacid@xxxxxxx>:
> El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
>> thanks for raising this topic!
>> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer <thomas.pfeiffer@xxxxxxx>:
>> > Hi everyone,
>> > I'm addressing both the Plasma team and kde-devel because this issue
>> > affects Plasma as well as many applications, and Valentin as the current
>> > maintainer of KWallet as well as KSecretService, a potential replacement
>> > for it.
>> > KWallet plays a central role in Plasma and many KDE applications as the
>> > central password storage. However, it being very old and not having been
>> > actively developed for a long time, it has lots of problems, including:
>> > - It has weak security, as it does not restrict applications accessing it
>> > by default, and even when it does, it does so simply based on application
>> > name which allows any malicious process to impersonate an allowed one
>> > - The initial setup has huge usability problems, as it forces users to
>> > make
>> > a choice on a very advanced technical level (encryption methods, no
>> > less!),
>> > and the option it suggests (GPG) is a nightmare to set up for ordinary
>> > users - It does support unlocking via PAM, but does not tell users what
>> > they need to do to make that work, which results in most users having to
>> > enter the KWallet password at each system start, which many find very
>> > annoying (we get lots of negative feedback for that)
>> > - It works only with KDE Frameworks-based applications
>> > - One cannot easily write a QML GUI for it, making it unsuitable for
>> > mobile
>> > Valentin has been working on KSecretService for quite a while, which is
>> > based on the freedesktop Secrets API  that is also supported in GNOME
>> > Keyring, and would solve many (and ideally all) of the above problems.
>> > However, Valentin told me he does not have the time to work on
>> > KSecretService any more.
>> > This means we have to find a solution to these problems. The options I see
>> > currently are
>> > - Improve KWallet (unlikely to fix all the problems without massive
>> > changes
>> > in it, though)
>> > - Find someone to finish and maintain KSecretService
>> > - Build a wrapper around one of the other existing keyring technologies
>> > - Each application (and each Plasma component that stores passwords)
>> > implements its own encrypted password storage
>> > - We make encrypted password storage optional and non-default (easiest
>> > solution, but not exactly in line with KDE's vision)
>> I disagree on this point. Even if KWallet were free of usability
>> issues, it would still provide a false sense of security. The user
>> thinks that his/her passwords are safe, while in fact they are not.
> How exactly the passwords are not safe?
The default behavior is to keep wallets "open" once they have been decrypted.
If a wallet is open, any process can trivially retrieve clear-text
passwords from it using the KWallet API. I wanted to back my claim
with some code, so I created a small PoC in . All an attacker has
to do is to guess the name of a wallet (and only if the default
'kdewallet' name is not used!).
I could also mention that KWallet accepts an empty master password,
which alone is already bad enough.
>> If we don't have enough manpower to develop and mantain a proper
>> keychain in Plasma, we should tell our users. This way they can make
>> sure that, for example, the unsafely stored Wi-Fi passphrase is not
>> used for other accounts. This is already closer to our vision than the
>> current situation.
>> My vote is: we either do it right, or we give up. If someone steps up
>> to fix this problem, great. Otherwise we should start to slowly port
>> away from KWallet.
>> > So, what do we do?
>> > Cheers,
>> > Thomas
>> > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secret
>> > s-api-0.1.html