On Friday, July 15, 2016 10:22:32 AM CEST Elvis Angelaccio wrote: > 2016-07-14 1:11 GMT+02:00 Albert Astals Cid <aa...@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.pfeif...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
