Bug 387418 - Password field allows deleted password to be restored with Ctrl+z
Summary: Password field allows deleted password to be restored with Ctrl+z
Status: RESOLVED DUPLICATE of bug 453828
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: 5.10.3
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: David Edmundson
Depends on:
Reported: 2017-11-28 20:27 UTC by Gecko (kraut.space Jena)
Modified: 2022-06-12 14:09 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Gecko (kraut.space Jena) 2017-11-28 20:27:15 UTC
I am using: 
KDE Plasma Version 5.10.5
KDE Frameworks Version 5.37.0
Qt Version: 5.9.1

When the screen is locked and unsuccessful attempts are made at unlocking with a password, the masking dots can be unmasked to the clear attempt text by clicking the eye button in the right corner of the password field. If the user then deletes the password attempt (and leaves their computer), an attacker is able to restore the deleted password attempt by pressing Ctrl+Z when the focus is on the password field. The restored dots can then be unmasked by pressing the eye button again.

The field history is not conserved (and can't be reversed) when the system is successfully unlocked and re-locked. However, I sometimes find myself distracted and leaving my workplace when unsuccessful in entering my password. An attacker could recover this attempt that will be almost the correct system password, and could try to trace and correct my typo.

It would make sense to deactivate entry history (being able to traverse inputs with Ctrl+Z and Ctrl+Y) for the password field on the lockscreen. I would like to have the option to deactivate the unmasking "eye button" functionality with the other screen locking options.
Comment 1 David Edmundson 2017-11-28 20:57:41 UTC
Practically no-one will type the right password then delete it...and the odds of an attacker stumbling across this at the right time seem incredibly flimsy. 

However, effective fix uploaded.
Comment 2 Christoph Feck 2017-12-20 15:52:54 UTC
Could you please add the phabricator link?
Comment 3 David Edmundson 2018-06-13 09:12:01 UTC
https://phabricator.kde.org/D9040 was the link. It didn't get in for reasons I don't really agree with, but meh.

I've also tried adding a key handler on the TextField to intercept it before Qt but that doesn't work as child events (which in QQC1 contain the real TextInput item) will get processed first. Only solution I can think of is a clone of our MouseEventFilter we have in kdeclarative.
Comment 4 Peter Wu 2018-08-17 09:25:04 UTC
This issue (Ctrl-Z revealing previous attempts) is still present in kscreenlocker 5.13.4-1 on Arch Linux.

Additionally, the reveal option also introduces another privacy issue: the clipboard contents can be extracted (Ctrl-V) and modified (Ctrl-C) (bug 388049).
Comment 5 David Edmundson 2020-01-15 10:44:08 UTC
Git commit 505ce9929b2f36d8e29330f0accfbb83d654a8cd by David Edmundson.
Committed on 15/01/2020 at 10:43.
Pushed by davidedmundson into branch 'master'.

[sddm-theme] Don't have a broken reveal password button

sddm-greeter will have a button for the reveal password button, but due
to sddm-greeter not loading a relevant QPT has no code to force it to
load the breeze icon set.

Without the breeze icon set, the clear button does not show.

There are ways to solve this, but none are trivial or reliable.

I threatened to do a revert in 5.12 (https://phabricator.kde.org/D9040)
but the bug has still not been fixed since.
Related: bug 396039

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26675

M  +1    -1    sddm-theme/Login.qml

Comment 6 Nate Graham 2020-06-03 14:16:24 UTC
*** Bug 422421 has been marked as a duplicate of this bug. ***
Comment 7 Oded Arbel 2022-06-12 11:00:24 UTC
isn't this a dup of bug #453828 ?
Comment 8 Nate Graham 2022-06-12 14:09:40 UTC
Yes indeed, thanks.

*** This bug has been marked as a duplicate of bug 453828 ***