Disable Secure Input?

#1

Outlook (Version 15.3) enables secure input and does not turn it off. Do you have any suggestions on how to prevent this?

Please note, the KM help message stated that 1Password, 1Password mini, or a browser extension running 1Password was probably the culprit. I have killed 1Password so many times along with all my web browsers trying to make sure that 1password could not mess me up. However, that was not the problem.

I could not find the application that was enabling Secure Input until I installed TextExpander.

TextExpander has a feature that tells me which application enabled the current Secure Input mode. TextExpander immediately told me that Microsoft Outlook was the culprit. I killed Outlook and restarted it and all was better.

So, as a work around, I either have to buy TextExpander, or suggest that KM provide a feature that will identify the application which enabled secure input. Would it be possible for KM to tell me who enabled secure input?

Thank you!

My software:
OSX 10.11 (15A284).
KM Version 7.0.1
Outlook (Version 15.3)

#2

The problem is that the system is in Secure Input Mode.

Secure Input Mode is a system security feature that stops the ability to monitor keystrokes while you are typing in a password field. Unfortunately, it sometimes gets stuck on such that the system thinks you are still in a password field even though you aren’t.

Keyboard Maestro reports that the system is in Secure Input Mode when it detects this case. 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.

Its very clever that TextExpander figures out which application is the culprit. I have no idea how they do that, I will have a chat with them.

There is a bit more about the issue on the wiki.

I suspect a case where it happens frequently is at login time where an application asks for a password while the system is still overwhelmed with launching applications, and thus notices the password request and turns on Secure Input mode but does not notice the application replaced at the front with another application and turn Secure Input mode off.

#3

Your explanation helps me to understand why KM is not able to turn the secure input mode off. I can see why there is no work around for that.

I wanted the group to know that textexpander figures out which application is the culprit, and that this ability is incredibly valuable. It also has helped me to figure out when the culprit application causes the problem. I hope that KM adds that feature to the product.

For those who are searching for answers in this forum, in my case, the culprit application was Outlook. Outlook as part of Office365, has an annoying bug on the Mac which causes it to frequently forget that it has been registered on the system through a login with Microsoft Office. The login registration has a bug as well which on two of my Macs, causes it to frequently fail registration. Whenever I have to re-register the Mac, the Outlook/Office365 web page puts the system into secure input mode. If the registration fails, it will leave the system in secure input mode. If it succeeds, it can also leave the system in secure input mode. Textexpander helped me figure this out. Now, when my system is stuck, I know which application to go and beat up to fix the system.

As the KM help message indicates that 1Password or LastPass are usually the culprit applications, I spent a lot of time trying to beat up 1Password to no avail. As I use 1Password, only after some serious reflection did I look beyond 1Password for the solution. So, the help message would be more helpful if it pointed to a list, perhaps on the web, of all applications that have been found to potentially create this problem, and the suggestion that installing Textexpander will lead to the culprit application. It should be noted that Textexpander does not always come up with the right culprit. In their forums, people mention that when Textexpander cannot figure out who the rogue application is, that Textexpander will state that the application is the “Login” application. If that is the named rogue, then you will probably not get to the bottom of the problem immediately.

Let me know if KM adds this feature! I love KM and do not want to have to install two products.

john

#4

Thanks to info provided by the fine folks at Smile Software, you can use the Terminal command:

ioreg -l -w 0 | grep SecureInput

That will tell you the process ID (kCGSSessionSecureInputPID) of the application that has Secure Input enabled. You can then use:

ps auxww | grep NNN

to find the process with the specified pid.

I will endeavour to add some support for this within Keyboard Maestro’s alert in the future.

Thanks again to the Smile Software, makers of great Mac software!

Keyboard Maestro “Find app with secure input” Macro
#5

@peternlewis:
Peter, I can’t begin to express how much I appreciate your perseverance to solve an issue, even though it may not affect that many users.

Most, if not all, other software manufacturers are very quick to point a finger at someone else (Apple, another app, etc), and just say sorry, there’s nothing we can do about it.

I really like your attitude of pushing to solve the problem no matter where it takes you. :+1:

#6

I have made a quick macro, which uses Peters shell commands:

I am sure somebody can optimize it.

Typed text string macros are not working
#7

Wrapped the whole thing up as a single JXA script without all the duplicate entries. Also gives you the option to quit the app if you want to.

Secure Input Detective.scpt.zip (1.4 KB)

EDIT: Changed to compiled script, noted it's JXA not AppleScript. Old habits die hard...

#8

Great! Thank you!

#9

Just so everyone knows what to expect, your script is not AppleScript, it is JavaScript for Automation (JXA).

Thanks for sharing.

#10

JavAppleScript? Too darn confusing, especially with the ".applescript"
extension on everything.

Edited above post with appropriate terminology and a compiled script. Thanks, JmichaelTX. :slight_smile:

#11

I know what you mean. And since compiled scripts all have the same extension of ".scpt", you can’t tell by the file name what language is used.

So I have developed a habit/naming convention of adding a suffix to the end of the file name, just before the extension, as in:

Secure Input Detective JXA.scpt
Some AppleScript script AS.scpt

This also helps when I want to search for only JXA or AS files.

#12

The latest version of Keyboard Maestro (7.1+) use the technique pioneered by Smile Software to display the suspected application that is holding Secure Input Mode.

#13

It told me it was loginwindow - but when I went to kill loginwindow, MacOS told me that would log me out.

I quit 1Password instead after reading the docs on the website - and that solved it

#14

Yes, loginwindow is basically the parent process of every other process in your login. So if the system isn't being clear about who the culprit is, then it can end up appearing as loginwindow.

#15

I'm running macOS 10.14 Mojave. No matter what I try, the Secure Input warning won't go away. The culprit is also the loginwindow process. Could this be an issue with Mojave and KM? I'm running latest version of KM, 8.2.4.

#16

Is Secure Input a particular process to look for in Activity Monitor?
I might then kill it…
(No luck killing all processes with "sec": they just restarted asking for password.)

#17

Hey @lwb52,

You can't disable Secure Input at the system level.

The best you can do is find out what application/utility is enabling it and quit that.

-Chris

#18

It turns out the app was “Authy” multi-factor authorization...