Secure Input not disabling after having copied a password
The problem
I'm experiencing this around 10-30 times per day, and have so for 5-6 months. The quickfix is super-easy, but having to do it 10-30 times per day is annoying.
Short version of the problem: Sometimes, after having copied a password from the quick-vault - or I'm I've created a new password and just alt-tabbed away from 1password, then secure input is still enabled. So shortcuts from Better Touch Tool is blocked.
If I just open 1password and close it (CMD+w), then my shortcuts starts working again. It seems as if 1password (or something) forgets to disable Secure Input Mode after having copied the password.
Debugging
I can't find anything about how to debug Secure Input Mode. Ideally I would like to see, when it has been invoked and by what piece of software, to ensure that 1password really is the culprit. Or perhaps trying to disable it (temporarily) to see if the problem goes away, which I highly assume.
Good post about this problem
- This answer here (by Peternlewis) describes what I assume to be the cause of the problem quite well: https://forum.keyboardmaestro.com/t/disable-secure-input/2410#post_2
- Here are someone else that probably has the same issue: https://apple.stackexchange.com/questions/331557/is-there-a-way-to-fix-or-disable-secure-input
What I've tried:
- I've tried asking on SuperUser ( https://superuser.com/questions/1472593/mac-how-can-i-see-if-secure-input-is-enabled-better-touch-tool-being-blocked ). But no one has weighed in.
What I'm after:
- Obviously, if would be awesome if I somehow could ensure this never to happen. If there is a setting or something that I could try, that would be great.
- Second best is a way, where I can see that Secure Input Mode is enabled, so I know when my shortcuts are working and when they are not.
1Password Version: 7.3.2
Extension Version: Not Provided
OS Version: 10.14.6
Sync Type: Not Provided
Comments
-
From Peternlewis's post:
It is not something Keyboard Maestro can “work around” - it is a system security feature that stops Keyboard Maestro or any app from monitoring the keystrokes, and would not be much of a seucrity feature if it could be worked around, so Keyboard Maestro cannot do anything about this except report the issue to you.
We're in a similar position. The system automatically flags all password fields for Secure Input. On top of that, we flag some additional fields in 1Password as such. My understanding is that we have no direct way of telling the system "hey, turn Secure Input off."
If I just open 1password and close it (CMD+w), then my shortcuts starts working again. It seems as if 1password (or something) forgets to disable Secure Input Mode after having copied the password.
We don't turn Secure Input off. We don't have that ability. It is up to macOS to determine when it should be turned back off.
Obviously, if would be awesome if I somehow could ensure this never to happen. If there is a setting or something that I could try, that would be great.
I'm not aware of any way of doing that; sorry. However, I can say that I make extensive use of TextExpander, which also relies on Secure Input being off. Also, as you might imagine, I use 1Password a fair bit. ;) I can't say I've experienced this problem. For me, Secure Input is enabled when expected and disabled when not needed. So, this may perhaps be something that can be resolved by changing behavior. When not using the 1Password app I dismiss it using the
⌘H
keyboard shortcut, and also make sure I'm not leaving any records in edit mode. You may want to give that a shot and see if that improves the detection any.Second best is a way, where I can see that Secure Input Mode is enabled, so I know when my shortcuts are working and when they are not.
I use TextExpander to tell me this, though I have found it isn't necessarily 100% accurate about which app is causing Secure Input to be enabled. It does seem to reliably indicate when Secure Input is on.
One other thing I might suggest is creating a new macOS user account and only running 1Password and Better Touch Tool in it. Make sure nothing else is running that might enable Secure Input. Note under which circumstances Secure Input appears to be enabled. That may help narrow things down.
Ben
0 -
Thanks for your response.
It's actually a good idea, always hiding it with CMD-H! I'll give that a shot and see if that make the inconsistencies disappear.
Do you (or anyone) know any other way than TextExpander to see if Secure Input Mode is enabled? I use Alfred myself and it doesn't show it visibly in the menu bar.0 -
@zethodderskov - any of the clipboard manager/modifier utilities ought to have a similar feature. Typinator (a TextExpander competitor) has a similar feature that you can see just from the menu bar icon:
This isn't an endorsement of one solution over any other, but it is indeed another option. I'm not certain whether Alfred provides you any way to enable a function to visibly see whether Secure Input is active.
0 -
A coding level answer to the question of is SecureInput enabled or not is:
IsSecureEventInputEnabled()
as defined in theHIToolbox/CarbonEventsCore.h
0 -
@Lars - Awesome! I'll give that a shot.
But what if I can prove (with a screencast or something) that it's the 1password that leaves the Secure Input Mode on, after having grabbed a password from the quick-search-vault. Do I then file a bug-report? Or can I just upload the screencast here?... And it has nothing to do with editting an entry in 1password. Nothing is being editted, when I experience this.
The CMD-H makes the problem dissappear, but it does add more interaction with 1password. And it's slower to open the main application than the quick-search-vault-function.
0 -
You're welcome to send us the screencast at
support@1password.com
, though as mentioned above, even if that is the case... we have no way of telling the system "turn off Secure Input now." The system determines when no fields that require Secure Input are being interacted with and is supposed to turn off Secure Input at that time. If that isn't happening properly, then either a field marked for Secure Input is still active somewhere, or there may be a bug in macOS. Considering this doesn't appear to affect everyone using 1Password alongside a tool that requires Secure Input be off, I would suspect less of the latter and more of the former. The fact that using ⌘H causes the problem to be avoided seems to further confirm that.Ben
0