The situation of KWallet, and what to do about it?

[Martin Graesslin]

On Friday, July 15, 2016 10:22:32 AM CEST Elvis Angelaccio wrote:
> 2016-07-14 1:11 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
> > El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
> > 
> > escriure:
> >> Hi,
> >> thanks for raising this topic!
> >> 
> >> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer <thomas.pfeiffer at kde.org>:
> >> > 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 [1] 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 [1]. 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.

yeah, once the wallet is open it's as secure as a simple plain-text file on an 
encrypted home. If the home is not encrypted kwallet does offer an advantage 
over a simple plain-text file.

If we assume that "if it runs, it's trusted" then everything is fine as well. I 
can see ways how this can be secure with containerized apps and e.g. dedicated 
privs the user has to acknowledge to have it read wallets. E.g. that a 
containerized app has to ask for password for application foo. This could 
offer a user a good and informed decision on whether to grant it or not.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160715/ae425dc0/attachment-0001.sig>