I think most of the discussion is going in the wrong direction.
Maybe fullscreen applications are "better" at faking password dialogs, but in the end, every application can show a password dialog.

The problem:
How to prevent the user to enter her password into a malicious/fake password dialog.
(eg faking a login screen, screen locker, packagekit authorization , ...)

To prevent this, any honest password dialog should authenticat itself to the person infront of the pc.
Wikipedia lists three categories of authentication:
- knowledge: something the user knows
- ownership: something the user has
- inherence: something the user is

Since the system wants to authenticat itself to the person infront of the pc, the system or the password dialog would be the user in this scenario.


Knowledge should be the easiest of the categories to implement, at least without some special hardware. So with every password dialog the system needs to authenticate itself to the person infront of the pc with something only the system and the user knows.
eg a picture, a 4 diget number, a short sentence

- the secret must not be available to other programms (this includes screencapture)
- the secret should be easily recognizeable for a human

Ofcause thats not perfect secure, but it would be more secure then the current way and its easy for the user.



It might be usefull to have a way to prevent applications to go fullscreen and to have some clear indication how to get rid of the fullscreen application (in an uniform way), but not for security reasons.

@fabianr, that are some very good thoughts. One of the ideas I also had was using KDE Connect to send a token to the smartphone as kind of two-factor authentication. Technically that might be tricky, though.

I just tried something with the result of me being sad: ksnapshot -> current screen -> 5 sec delay, lock screen, wait, unlock screen and the lock screen is captured. Oh X11 you are sooo broken.

Sounds like we need to delay that for Wayland, too.

Since the smartphone is not something the system owns, I don't think this would be regarded as a two factor authentification for system -> user . (Only for authentication user -> system). The user would have two screens instead of one, that claim: "This is a valid password dialog". But still no way to check if those are really is legit.

As I can't think of any way to use inherence factors in this scenario, I belive, to have a two factor authentification one would need something that the system owns. Eg some hardware only accessible for the system that provides visual feedback to the user, if a legit pwd dialog is active.

I thought some more about my proposal, that the system displays some commen secret with each pwd dialog. It might work pretty good for a system thats only used by one user or a small trusted group of users, but won't work well with a system used by a large group of users. The shared seceret of each user would be visible to each user on the login screen. Unfortunatelly the only solution I found so far for this problem would be a 3 way authentication.
1) user enters her "pin"
2) system displays the comon secret
3) user enters her pwd

The downside is, that the user needs to remeber a second password, the pin. And the user needs to be educated, that if step 2 does not happen, she NEEDS to change the pin should. And check for maleware or call the admin ...



Oh and just another reason why fullscreen security won't protect the user from malicious/fake password dialogs:
As soon as the browser has the right to go fullscreen, any page the user visits could create a fake password dialog, even in fullscreen. Hacked servers, honey traps, ...

IIRC, Windows NT made it so one had to press Ctrl+Alt+Del to log in, to make sure that users only input their password in an actual login dialog.

Could we do something similar? When a password is needed, the password request would be sent to a system-password-request, and a dialog telling the user to push Ctrl+Alt+Del[1] to input the password could be displayed.

If it's consistent, we could train the users to always push Ctrl+Alt+Del[1] whenever they're about to enter their password.

Or?

[1] Any other key-combination which only the system can catch would do I suppose, but Ctrl+Alt+Del would be known for users migrating from Windows at least.

fabianr wrote:Oh and just another reason why fullscreen security won't protect the user from malicious/fake password dialogs:
As soon as the browser has the right to go fullscreen, any page the user visits could create a fake password dialog, even in fullscreen. Hacked servers, honey traps, ...

Of course if a faked page tricks the user to believe it's authentic and to allow it to go fullscreen, that user is screwed. That does not mean that we might as well just throw in the towel, though. If that was the case, browsers would never have bothered asking the user for confirmation before showing a page fullscreen, either (as of course if the user thinks the page is authentic, they will allow it to go fullscreen). No security mechanism is ever completely proof against social engineering, ever. If I convince you that I'm your company's CEO and it's absolutely critical that you enter you insanely complex password, use your key and finger print to do X or else you'll get fired, I've won as well. That doesn't make all those security mechanisms obsolete, though.

I don't read whole topic, but maybe displaying image on screen locker is an good idea? User may select image in KCM. Only screen locker and special kdesettings5's module would have rights to read this image.

I have an idea.
1. Add global keyboard shortcut, which will display outer lines on each window, which is secured by Wayland. User will only press MetaKey(for example only) and he knew if window are created by Wayland or it's secured. This combination cannot been grabbed by any other program (it's possible)?
2. Add information in title bar, which window is secure (For example Secured - Firefox). If KWin detects Secured or Really word on start of title, it will add word "Not really" at start.

About way to protect user with input to wrong dialog - password dialog should display warning, when it doesn't have focus.

Maybe in other way - allow to tell the compositor "I'm the password dialog". Once this dialog have input, compositor won't change focus or show warning (partially transparent of course) that focus will be changed in x seconds. Additionally, there could be sound added for insecure cases, like changing focus from secure control into insecure one.