While You Won’t Find Absolute Password Protection, There Are a Number of Techniques Available to Help Hide Your Secrets

Computer security is one of the major issues of these times. How do we protect our data? Even after all of the latest innovations in cybersecurity, we hear about hacks of major sites and institutions. With all the ways we use today’s computers, we want to feel as safe as possible.

Caution: Human error (e.g. opening the wrong attachment, not changing passwords, etc.) offers the number one opportunity for the bad guys to invade your privacy. If someone gains access to your computer, then you have virtually no protection. Some people either don’t add a password to their Windows computer or allow autologin when the machine boots up. That’s a mistake! Always require password login to access your Windows computer. Otherwise, you make it too easy for people who stumble upon your computer—either in your office or cyberspace.

You’ll find a multitude of encryption and password protection systems available. How far you feel you need to go depends upon your own computing habits and the type of data you keep on your computer. Most people have something they want to protect. Once a person with enough smarts gets on your computer, he or she can most likely figure out how to get to your passwords and certain encrypted data.

AutoHotkey does not offer tools for protection from people who get physical access to your computer—either in person or remotely. Anyone with computer skills can bypass attempts at obfuscating your data with AutoHotkey. However, you’ll find a couple of techniques useful for adding a simple layer of protection to your AutoHotkey scripts. Fortunately, most people do not own abundant computer skills. If you can sufficiently confuse the intruder, you’ll make it more difficult for that interloper to get to your stuff.

While not a cure-all, you can take a few steps to help shield critical data in your AutoHotkey scripts:

1. Do not save usernames or passwords as plain text in AutoHotkey scripts, INI files, or other text type files. (I use the Windows Registry.)
2. Use Hide (InputBox command) or Password (Gui, Add, Edit command) options to obscure passwords entered in plain view of other people.
3. Partially conceal critical data by compiling the AutoHotkey script into an EXE file.
4. Set AutoHotkey scripts as hidden files in Windows.

Note: I would not depend upon the last two as a form of protection. While they may prevent the average computer user from accessing your data, they won’t stop the knowledgeable and they can make your own AutoHotkey use cumbersome.

If you use AutoHotkey script to autologin to sites, then most likely the sites use a secure connection (HTTPS://). In these situations, the site server sends you an encryption key which scrambles all data sent to and from the site. This should protect your data traveling outside your computer, but prior to making that secure connection, data on your computer (e.g. passwords embedded in AutoHotkey scripts) may be vulnerable to intruders.

Hiding Usernames and Passwords

Usernames and passwords make up the two most common forms of data needing protection. We use them to access our various systems both on our computer and, more commonly, on the Web. If someone gets ahold of these two pieces of information, they can get access to our critical accounts. Every time we log into one of our secure locations, we enter a username and password.

As AutoHotkey users, it’s only natural to automate the login process—supplying both the username and password via a script. Including the login credentials within a script as plain text is a common mistake. If anyone happens to get a copy of the script, they immediately hold everything needed to break into one (or more) of our accounts.

Some people attempt to hide data in an INI file or another text data file. However, these types of extra files are just as easy to open, copy and/or read. Some people employ encryption techniques to hide the information, however, most schemes require an encryption key on the same computer and often use another password which also needs hiding.

If you own an encryption program which AutoHotkey can use to retrieve data, then great. But that could be overkill. As shown in the previous blog, I use the Windows Registry to save this type of data because, by default, Windows does not allow remote access into the registry. While a hacker may copy all your AutoHotkey scripts and INI files, getting into the Windows Registry offers a bigger problem for the nefarious.

Even if someone reading an AutoHotkey script sees where in the Registry you have saved your password, without Registry access they won’t be able to get to it. (Many people who happen to get on your computer while sitting in your home office won’t have the first idea about how to access your Windows Registry.)

Note: I’ve seen some AutoHotkey scripts which encrypt data—some complicated (full encryption) and some simple (e.g. word splitting or character reversal). While I have no problem with wanting to further scramble key data, understand that people who know AutoHotkey can decipher how it’s done and reverse engineer the process from the original script.

To save your password to a Registry locations use the RegWrite command:

RegWrite, REG_SZ, HKEY_CURRENT_USER, Software\TestKey
        , MyValueName, MyPassword   ; Plain test password

(Word wrapped using AutoHotkey line continuation techniques for display purposes.)

If the key does not exist, AutoHotkey creates it.

Of course, the line above shows the password in plain text (“MyPassword“). To prevent your password from appearing in the .ahk script, use the InputBox command or the Edit GUI control with a shielded variable (%Password%)—as shown in the “AutoHotkey Password Protection from Prying Eyes” section below:

RegWrite, REG_SZ, HKEY_CURRENT_USER, Software\TestKey
        , MyValueName, %Password%   ; Variable password

(Word wrapped using AutoHotkey line continuation techniques for display purposes.)

Use the RegRead command to retrieve the password:

RegRead, Password, HKEY_CURRENT_USER\Software\TestKey, MyValueName

This way your password (or username) never appears as plain text in the script.

Remember, avoiding inadvertent exposure is the goal. If someone already has access to your computer then you’re already in trouble.

While running, the password value does appear in the ListVars window.  If you open the running script (ListVars command), the saved variable appears as plain text. However, you can limit even this short exposure by setting the Password variable to blank immediately after retrieval and use:

Password := ""

Now, how do you enter a password in a running script without exposing it?

AutoHotkey Password Protection from Prying Eyes

Two AutoHotkey commands allow you to hide your input while entering a password (or other confidential information): the InputBox command and the Edit GUI control. Realize that these features in the InputBox command and the Gui, Add, Edit command do not encrypt the input text. They merely hide the characters as you enter them. That prevents someone from looking over your shoulder in the local coffee shop and reading your password. Within the script, AutoHotkey does not encrypt the contents of the variable:

InputBox, Password, Password, Enter Password, Hide, 200, 125

By adding the Hide option to the InputBox command, AutoHotkey displays asterisks rather than the characters as you type your password.

Next, you can use the RegWrite command line shown in the last section to save the password to the Windows Registry.

You add the same masking effect to a GUI window by including the Password option in a single-line Edit control:

Gui, Add, Edit, Password vPassword2
Gui, Add, Button, ,Submit
Gui, Show

If you want an asterisk rather than bullets as the masking character, append it to the option (i.e. Password*). In this example, you would need the Label subroutine ButtonSubmit to save the value of the password to the variable Password2:

ButtonSubmit:
  Gui, Submit
  MsgBox %Password2%
Return

The sole function of text masking is to obscure entered text from open view.

Compiling AHK Files Offers Minimal Security

In many programming languages, compiling scripts into EXE (executable) files actually converts the code into human-unreadable binary files. While compiling an AutoHotkey script does make it executable without needing AutoHotkey installed on the Windows computer, it does not obscure the actual code. If you open the EXE file with Notepad—an action most people won’t likely consider—you can search for and find the text from the compiled script—including any embedded usernames or password.

If you do embed critical data in an AutoHotkey script, compiling it into an EXE file will fool most people, but don’t deceive yourself into thinking you have actually encrypted the data.

Set Windows AHK File Settings to Hidden

Another trick which may hoodwink the average computer user hides the Windows file through the file’s the Properties window (right-click context menu, select Properties, check Hidden under the General tab, then Apply). This removes the script name from the Windows File Explorer listing. Most people will not know the script even exists. However, the experienced Windows know how to make all hidden files visible by resetting the View in Folder Options.

If you employ this method for hiding files, you may want to set up shortcuts to run any hidden scripts since you can’t double click on an invisible filename.

Click the Follow button at the top of the sidebar on the right of this page for e-mail notification of new blogs. (If you’re reading this on a tablet or your phone, then you must scroll all the way to the end of the blog—pass any comments—to find the Follow button.)

This post was proofread by Grammarly
(Any other mistakes are all mine.)

(Full disclosure: If you sign up for a free Grammarly account, I get 20¢. I use the spelling/grammar checking service all the time, but, then again, I write a lot more than most people. I recommend Grammarly because it works and it’s free.)