obviously that wouldn't protect against your most favorite style attack

mgraesslin wrote:I don't know how it works, but over a wayland connection one gets the PID, UID and GID of the connected client (see wl_client_get_credentials).

I had assumed it was simply provided by the client.
Since *all* wayland clients will provide this, you can perform a sanity check (do we have this pid for another client? does that PID, UID and GID combo exist?) and therefore it will become a problem for another client to feign <BROWSER> by sending PID etc. of an actual <BROWSER> process (since the client already is registered).

Operating on time security could indeed *help* on KWallet:
Any ever possibly interested process *has* to establish a secured connection within limited PID time (eg. 500ms), providing it's PID.
KWallet can then perform a sanity check (on linux and BSD w/ proc) and deny taken or out of time PIDs and inspect /proc for the binary path.

That's not 100% secure, but the client can tell the user when it failed to access kwallet (UH-OHH!!!) and of course makes it very hard to feign a connection.

This would likely rather be done by QSslSocket than by QDbus.

"KDbus will fix it"

AFAIK that allows you to check the PID of the sender; providing we don't end up abstracting it.

luebking wrote:

colomar wrote:So KWallet makes it look like it's secure when in fact it isn't, therefore reducing overall security.

The prompt is off by default:

_openPrompt = walletGroup.readEntry("Prompt on Open", false);

although I believe that was changed only a year ago or so (so maybe you've a setting to show it intact?)

I know it's off by default and it's off on my system. My argument is that a feature which pretends to make KWallet more secure but in fact adds pretty much no objective security at all should not even be there!
This is a feature which more security-conscious users (who lack the technical knowledge to know it's snake-oil) might switch on actively, thinking it would satisfy their security requirements.

Of course the preferred way is to completely prevent a threat (i.e. what you guys have been discussing in the last few posts). If that is not possible, however, the next best thing to do is making users aware of the risk so they can make an informed decision whether it is a risk worth taking or not.

Therefore, unless we can make KWallet secure, we have to get better at communicating to the users what they're getting themselves into.

colomar wrote:Therefore, unless we can make KWallet secure, we have to get better at communicating to the users what they're getting themselves into.

I completely agree! Suggestion: start a new thread and come up with a mockup for a "warning" and then approach the KWallet developers with it.

mgraesslin wrote:

colomar wrote:Therefore, unless we can make KWallet secure, we have to get better at communicating to the users what they're getting themselves into.

I completely agree! Suggestion: start a new thread and come up with a mockup for a "warning" and then approach the KWallet developers with it.

I'd even say to simply remove that option and all autorization management (kwallet is friendly enough to store authorized clients unencrypted...)
KWallet is not secure and this doesn't make it secure - so why should anyone opt into self annoying?

However, afair KF5 will see KSecretService anyway? (Though I don't know what that looks like securitywise)

luebking wrote:I'd even say to simply remove that option and all autorization management (kwallet is friendly enough to store authorized clients unencrypted...)
KWallet is not secure and this doesn't make it secure - so why should anyone opt into self annoying?

I fully agree with removing the authorization management feature as long as it doesn't add to security.
The warning thing was about the risks that passwords stored in KWallet are subjected to (with or without authorization), so that users can make an informed decision about which passwords they want to store there. But Martin is right: We should start a new thread for that.