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. [1]: https://quickgit.kde.org/?p=scratch%2Felvisangelaccio%2Fkwalletleak-poc.git&a=tree Cheers Elvis > > 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 > >
