Hi all, Bhushan asked me to kick off a discussion on frameworks-devel about a problem we face for otpclient. We are looking for help in deciding how to best implement storage of the secrets which are needed by the app. Any insights from people who are more familiar with frameworks would be much appreciated!
To give a bit of context: otpclient is an app (flatpak) to generate two factor authentication login codes, similar to Google Authenticator. One thing the app needs to do is to store the 'secret' associated with each configured account securely, because the security of the 2FA relies on it. Effectively, this bit of data is just as sensitive as the main password to the account. Right now otpclient does not yet implement this (securely) and one reason for that is we are still not sure how we should do this in a KDE context. I suppose from our perspective the main questions are: 1. What Qt or KDE framework is appropriate for this? 2. If there is no such framework, then what KDE technology could possibly serve as the basis for such a library? And should it become part of frameworks? 3. How should this work? In particular in the context of apps such as flatpaks? We are aware that KWallet ant Qt Keychain exist but we have some concerns there: 1. (On KDE) these libraries wind up calling dbus. We would like to avoid plain text out-of-process communication of secrets, especially communication through a 'shared' channel (for obvious reasons). 2. In particular with KDE Wallet it was suggested that the wallet itself may, in fact, not be encrypted. Another possible contender is Plasma Vault, but we don't really know how that would work in the context of an app, especially a flatpak app. Ideally we could use something that offers the following: 1. Operating on encrypted files, which are encrypted and decrypted on the fly. This would facilitate an easy import/export scheme for the app (backups!), and should also work in the context of flatpaks. 2. Ideally while being unopinionated about what is stored "inside" the encrypted file 3. Easy to present to the user in terms of UX. It should not be necessary to do some kind of local setup first before being able to use the app, the otpclient should work as secure as we can make it out of the box. 4. Consumed as a library which does not need to 'talk' over unsecured channels. This would help avoid leaking secrets and make it easier for otpclient to control the lifetime of secrets held in memory. I.e. we would be able to flush secrets if we detect that the computer is about to suspend or on idling for too long. In particular we do not need lots of system integration, and we do not necessarily have to be super portable yet. So with all that said: what do you think? How should we tackle this? Can KDE offer framework level support for this? And if so, what would be the framework for that?