Password field security and information leaking

[Michael Pyne]

On Sun, Oct 14, 2018 at 11:19:17AM +0200, Ivan Čukić wrote:
> Hi all,
> 
> 
> We are using QLineEdit (and QML equivalent) all over KDE for passwords. This 
> is an issue for types of attacks that extract raw process memory because the 
> passwords can be leaked.
> 
> *snip*
>
> Transporting passwords via DBus (KWallet) is the problem 5 (guessing there's 
> no need to explain this one in more detail).
> The only remaining problems are 1 and 5.
> 
> *snip*
>
> Now comes the most interesting part (IMO). which solves problem 5 and also 
> influences the previous issue of having the decryption key in memory.
> 
> We can use a stream cipher to encrypt the password in memory. This means that 
> the password characters can be encrypted one by one as the user types them in 
> - no need to have the whole password unencrypted in memory at any point in 
> time during password entry.
> 
> If we use public/private key encryption, where the password entry is in one 
> process, and the password usage is in another, only the password usage process 
> will be able to decrypt the password (and, again, there will be no need to the 
> whole password to be decrypted at once - just one character at a time can be 
> sufficient in many use-cases). This means that the attacker will need to have 
> either access to the memory spaces of both processes, or to hit a very narrow 
> window in the 'usage process' between 'I got the password' and 'I used the 
> password and zeroed-out the data'.
> 
> The pub/priv key exchange can be done mostly securely using Diffie-Hellman 
> protocol similar to what the Secret Service API [2] does. The only attack 
> vector would be to replace the normal dbus server with a malicious one. In 
> that case (having a malicious system component), I'd say the systems is 
> already compromised and that we can not do anything to protect the user.
> 
> 
> Thoughts?

This all makes sense, your listing of problems and solutions.

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?

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?

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).

Regards,
 - Michael Pyne