Password field security and information leaking

[Ivan Čukić]

> It seems to me that a notional end-user application is the one that
> actually needs to *use* the password though, which might imply that the
> U/I for entering the password needs to be in a different process?

Depends.

I investigated all of this primarily for Plasma Vaults. The implementation is 
split into a Plasma applet and a kded module. Currently, the password 
requesting UI is in the kded module because I didn't want for it to go between 
processes in an insecure manner.

With the proposed change, the password entry could go into the Plasma Applet, 
where the password user would be the kded module.

I think the same organization would be fitting for some other applications as 
well. Consider KMail - password entry is in KMail, while the Akonadi agents 
are the users.

> Or might it instead be possible to split things up even more, so that
> end-user applications speak to an authentication agent, which performs
> authentication on the application's behalf, and the agent itself handles
> U/I separately? Again, similar to existing GPG and SSH model.
> 
> The downside I see is that it might be confusing and distracting for
> users to do 99% of their application configuration inside the
> application itself, and then have to go through an "auth agent popup
> window" experience for the authentication piece only.
> 
> But even there, if the application is able to use a secure password
> entry widget, it could perhaps be possible to be able to safely set or
> update authentication credentials in the same app config U/I (i.e. have
> the app itself serve the pinentry-qt role).

This sounds interesting. Let's see how this evolves. I'll use Vaults as a 
guinea pig, and I'll try to make it generic enough to support both single-
process entry+usage and the previously mentioned split.

I agree that it would be awkward to have the password entry outside of an 
application. If it's in the same process as the password user, I'm not sure 
doing a roundabout through an agent would have any benefits. Unless the agent 
also serves for 'remembering' the password like some KWallet++ (the formerly 
planned KSecretService). 

> GPG and SSH already have some facilities for handling this use case, I
> think. Would it be possible to e.g. use pinentry-qt for this?

Pinentry communication is not encrypted. But, we could provide a nice 
pinentry-kde if we wanted that supports the pinentry protocol and adds our own 
extensions for encrypted communication.

Cheers,
Ivan




dr Ivan Čukić
KDE, ivan.cukic at kde.org, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12