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

Albert Astals Cid aacid at kde.org
Wed Jul 13 23:11:55 UTC 2016


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?

Cheers,
  Albert

> 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
> 
> Cheers,
> Elvis
> 
> > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secret
> > s-api-0.1.html




More information about the Plasma-devel mailing list