Bug 412252 - When entering a wrong password, it will stay on screen indefinitely after the failed login attempt
Summary: When entering a wrong password, it will stay on screen indefinitely after the...
Status: RESOLVED FIXED
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: 5.10.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Nate Graham
URL:
Keywords:
: 374074 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-23 17:46 UTC by kolAflash
Modified: 2020-07-03 14:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.20


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kolAflash 2019-09-23 17:46:10 UTC
In one sentence: When entering a wrong password, it will stay on screen indefinitely
after the failed login attempt.
Same happens if not pressing enter after typing the correct password.

This problem is nearly completely similar to a problem for SDDM described here:
https://github.com/sddm/sddm/issues/1199



= Scenario =

-- password isn't deleted --

The user leaves it's PC after a failed login attempt.
(e.g. because he just realized it's lunchtime and another login attempt
would be useless, or because the fire alarm strikes)

A local attacker now has the chance, to look at the screen.
He will not just see the length of the password (number of asterisks).
But he will also see the typed text by clicking the eye-icon beside the
password field.

Assuming the user just did a minor typo (e.g. missed to press shift for
the correct letter), I consider this a security problem.
Example:
User typed: MyDogiscalledjohn
Real password which can be easily guessed: MyDogiscalledJohn


-- undo/repo issue --

Even if the user knows about this problem and deletes the password
(backspace or del key), the attacker can simply press ctrl-z to restore
the password.

The only chance for the user to securely wipe the password from the
screen, is to either correctly login and lock the screen again, or to
press ctrl-z to drop the undo-stack and enter a dummy text to also drop
the redo-stack.


-- comparison with unlocked screen --

You could try to compare this scenario with an unlocked screen. This is
also a problematic situation, but there are two aspects which make this
less critical:
- An attacker can't see the users password.
- The screen will lock after the configured time.
And the login/lock screen doesn't even delete the password after some
time (compared to the screenlock timeout).

I guess for the login screen there's not even an applyable timeout
setting, because the lock setting is per user and not system wide.



= Mitigations =

Deleting the password immediately probably isn't very handy for the
user. Having the possibility to see a misstyped password to correct it,
by clicking the eye-icon after a failed attempt, is probably very useful.

But I suggest the following mitigations:

- Disabling undo/redo in password fields.

- Deleting passwords from password fields after $time.
(independently if the user pressed enter or just left the PC after
typing something)


$time may be:

- A hard coded value. E.g. 60 seconds.

- For the lockscreen it might also be the configured time to lock after
inactivity. But I don't like this choice, because users may set a too
long time for this (e.g. 5 minutes), so their screen doesn't lock too fast.

- An new setting, which could be system wide (for the login screen) and
per user (for the lockscreen).


-- further thoughts --

Those mitigations might be a good default for all password widgets in
KDE/QT.

Password fields in all scenarios should probably not offer the
possibility to read their contents for an infinite time.
Comment 1 Nate Graham 2019-10-07 03:28:56 UTC
Deleting the text after a certain period of time doesn't seem unreasonable, but it isn't exactly a complete fix.

Not having a button show the password would fix this, but I imagine some people like that button.
Comment 2 David Edmundson 2019-12-06 19:39:06 UTC
*** Bug 374074 has been marked as a duplicate of this bug. ***
Comment 3 kolAflash 2019-12-10 04:00:59 UTC
(In reply to Nate Graham from comment #1)
> Deleting the text after a certain period of time doesn't seem unreasonable,
> but it isn't exactly a complete fix.
> 
> Not having a button show the password would fix this, but I imagine some
> people like that button.

Exactly what I think.

And disabling the undo feature should be without significant disadvantages.
Comment 4 Daniel 2020-01-11 22:34:13 UTC
Maybe it would be a good idea to expose this to the user:

- A setting wether the enable the "show password" button
- A setting wether to clear failed passwords immediately after pressing enter
- A setting of the timeout-time after which inputted passwords (without enter) are cleared.

You could add also a warning which security implications result of their settings.
Comment 5 Nate Graham 2020-06-03 14:37:07 UTC
Working on this.
Comment 6 Nate Graham 2020-06-08 16:52:15 UTC
Git commit b3030730d816631e6fd5a45f1c597ab07c073b52 by Nate Graham.
Committed on 08/06/2020 at 16:52.
Pushed by ngraham into branch 'master'.

[Lock screen] Make clearPassword() do what it says and then use it
Right now the clearPassword() signal does not actually clear the
password; it only selects all text. This is a violation of its name
as well as being pointless since there's no longer a way to see the
unmasked text, which means you always need to re-enter the whole
password anyway.
FIXED-IN: 5.20

M  +2    -2    lookandfeel/contents/lockscreen/LockScreenUi.qml
M  +1    -1    lookandfeel/contents/lockscreen/MainBlock.qml

https://invent.kde.org/plasma/plasma-workspace/commit/b3030730d816631e6fd5a45f1c597ab07c073b52
Comment 7 Nate Graham 2020-06-08 16:59:25 UTC
Not actually fully fixed yet. But it will be fixed by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/46
Comment 9 Nate Graham 2020-07-03 14:18:19 UTC
This has been done for 5.20.