Bug 401057 - Password typed during grace period is passed through to the foreground app, and can become visible
Summary: Password typed during grace period is passed through to the foreground app, a...
Status: RESOLVED WORKSFORME
Alias: None
Product: kscreenlocker
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-15 08:07 UTC by rugk
Modified: 2022-12-04 05:15 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rugk 2018-11-15 08:07:01 UTC
When your screen locks, and you do not notice you can just move the mouse, but enter the password, it may get written into an open text editor window or o.


STEPS TO REPRODUCE
1. Open a text editor.
2. Wait for KDE to lock the screen/fade out.
3. Pretent you did not see this and directly try to enter the password.

OBSERVED RESULT
The screen is quickly unlocked and you write your password into the open text editor.

EXPECTED RESULT
Maybe KDE can block this first input, so your password is not revealed in plain-text.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Leap 42.3
(available in About System)
KDE Plasma Version: 5.8.7
KDE Frameworks Version: 5.32.0
Qt Version: 5.6.2

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2018-11-15 22:40:11 UTC
I don't understand. After #2, you should be looking at the lock screen. Text entered in the lock screen should stay on the lock screen. Are you saying that after the screen unlocks, your password has been entered into a text editor?
Comment 2 rugk 2018-11-17 13:19:51 UTC
Yes, the screen unlocks and this is expected.

Because maybe I missed to say you have to be fast and enter the text directly after a few seconds after screen lock. Because the screen lock is so "soft" when locking automatically after the first few seconds, so you can still move the mouse or press a key and it automatically unlocks.

As such, you may just have a look during this time and when you then type your password to unlock it you accidentally trigger the "automatic unlock" and type your password in whatever input field is selected.
Comment 3 Nate Graham 2018-11-26 05:28:31 UTC
Try as I might, I cannot reproduce this issue.

Could you attach a video that depicts the problem occurring? You might need to point your phone at the screen for this.
Comment 4 rugk 2018-11-26 10:06:45 UTC
Maybe it is some adjustment by OpenSUSE or so? Don't know whether this is default behavior. 

I could screencast it, but it is exactly the same behavior as I describe. Just enter your password directly after the screen (automatically) locks.

So what exactly cannot you reproduce? Does the "move mouse only seconds after automatic screen lock" not work or what?
Comment 5 Nate Graham 2018-11-26 14:44:55 UTC
(In reply to rugk from comment #4)
> I could screencast it, but it is exactly the same behavior as I describe.
> Just enter your password directly after the screen (automatically) locks.
> 
> So what exactly cannot you reproduce?

After the screen locks and I enter my password in the lock screen, it doesn't show up in an open app with a text field.

The reason why I requested a screencast is because I cannot reproduce the issue as described, and often a video helps to illustrate exactly how you're triggering it.
Comment 6 Harald Sitter 2018-11-26 14:51:19 UTC
Moving to screenlocker.
Comment 7 rugk 2018-11-27 19:28:16 UTC
Hmm, it's hard to do this screencast and redact it properly etc.

However, may you first be able to answer this question:
> Does the "move mouse only seconds after automatic screen lock" not work[…]?
Comment 8 David Edmundson 2018-11-27 19:57:30 UTC
I assume you're saying you start typing your password whilst you still have the lock screen grace timeout. At which point typing dismisses it and then 

You can avoid that by setting "Require password after locking" to immediate. Is that what you're referring to?

I do want to change the UI whilst we're still in the grace mode so that the textfield isn't visible or maybe even just keep everything black and fade in. I don't think there's any feasible other behavioural change we can make.
Comment 9 Bug Janitor Service 2018-12-12 03:44:16 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 10 Bug Janitor Service 2018-12-27 03:44:27 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!
Comment 11 Nate Graham 2018-12-27 04:27:13 UTC
Seems like this is a real issue: if you type your password during the grace period (default 5 seconds), it will be entered into whatever text field was focused, if any.
Comment 12 Wyatt Childers 2021-02-22 22:12:06 UTC
I believe I'm experiencing this on 5.20.x packages in Fedora or something very similar. I'm not sure why but it seems like something has changed in the last couple of weeks. 

I have had the same password for years for unlocking desktop computers. I've never done this with any messenger, and my usage of messengers hasn't increased. However, in the past couple of weeks, I've leaked my computer's password half a dozen times in various messengers -- sometimes not realizing till someone points it out. 

It seems like there might be more going on here than just the 5 second grace period. It seems to be related to my monitors turn off from power management (which happens after the screen should've locked from going idle -- 10 minutes until power off, 5 minutes until lock).

Perhaps a regression in the 5.20.3,4 -> 5.20.5 cycle? I don't see recent commits that would suggest such a change. I also don't believe I've changed my behavior unlocking my screen though, so this is exceptionally confusing. I'll try to be more aware of what might be causing this, and intentionally try to reproduce it.
Comment 13 Wyatt Childers 2021-02-22 22:47:52 UTC
(In reply to Wyatt Childers from comment #12)
> I believe I'm experiencing this on 5.20.x packages in Fedora or something
> very similar. I'm not sure why but it seems like something has changed in
> the last couple of weeks. 
> 
> I have had the same password for years for unlocking desktop computers. I've
> never done this with any messenger, and my usage of messengers hasn't
> increased. However, in the past couple of weeks, I've leaked my computer's
> password half a dozen times in various messengers -- sometimes not realizing
> till someone points it out. 
> 
> It seems like there might be more going on here than just the 5 second grace
> period. It seems to be related to my monitors turn off from power management
> (which happens after the screen should've locked from going idle -- 10
> minutes until power off, 5 minutes until lock).
> 
> Perhaps a regression in the 5.20.3,4 -> 5.20.5 cycle? I don't see recent
> commits that would suggest such a change. I also don't believe I've changed
> my behavior unlocking my screen though, so this is exceptionally confusing.
> I'll try to be more aware of what might be causing this, and intentionally
> try to reproduce it.

After some diagnosis, this is indeed a different issue, see: https://bugs.kde.org/show_bug.cgi?id=433452

What changed is I started using elisa which for some reason suppresses power management like a video player.
Comment 14 Nate Graham 2022-11-04 21:04:09 UTC
Cannot reproduce on Wayland with Plasma 5.26.

As it has been a while since it was reported, can we please ask you to see if you can reproduce the issue with a recent software version? Like Plasma 5.25, or ideally 5.26?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Comment 15 Bug Janitor Service 2022-11-19 05:14:21 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 16 Bug Janitor Service 2022-12-04 05:15:52 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!