Encrypted attribute

You can use the encrypted attribute to encrypt the input key sequence contained in the value attribute (the String field). When you encrypt the contents of the value attribute, Host On-Demand stores only the encrypted version of the input key sequence into the macro script (in the <input> element) and does not retain the plain text (unencrypted) version of the input key sequence.

For example, Figure 1 shows an <input> element with an unencrypted input key sequence ('myPassword'):

Figure 1. <input> element with unencrypted input key sequence

input value="'myPassword'" row="20" col="16" movecursor="true"
          xlatehostkeys="true" encrypted="false" />

In contrast, Figure 2 shows the same <input> element with the input key sequence encrypted (I7xae6rSVlVFF6qzhWRfKw==). Notice that in this example the encrypted attribute of the <input> element is set to true:

Figure 2. <input> element with encrypted input key sequence

input value="I7xae6rSVlVFF6qzhWRfKw==" row="20" col="16"
          movecursor="true" xlatehostkeys="true" encrypted="true" />

In the macro editor, an encrypted input key sequence is displayed with asterisks (for example, the encrypted version of 'myPassword' is displayed in the String field as ************************ rather than as I7xae6rSVlVFF6qzhWRfKw==).

Encryption allows you to include confidential data, such as a password, in an Input action without exposing the confidential data to casual view. An unauthorized person cannot discover the confidential data by viewing the macro script with a text editor, with the macro editor, or in the source view.

After you encrypt the input key sequence, Host On-Demand does not allow you or anyone else to use the macro editor or the source view to decrypt it. Host On-Demand does not decrypt an encrypted input key sequence of an Input action until the macro runtime processes the Input action during macro playback. When the macro runtime processes the Input action, the macro runtime decrypts the encrypted input key sequence and types the unencrypted version into the session window beginning at the specified row and column location.

Typically in a 3270 or a 5250 environment, for a confidential input key sequence such as a password, the host application creates a non-display input field as the destination of the input key sequence, so that blanks or asterisks (*) are displayed instead of the plain text.

However, a security exposure still exists if the macro script is exposed to more than casual view. A clever foe who gains access to a copy of the macro script can discover the original unencrypted input key sequence by editing the row and column fields of the Input action so that during macro playback the macro runtime types the decrypted input key sequence into a normal display field.

For greater security, you can use a Prompt action instead of an Input action. With a Prompt action, the input key sequence is not stored in the macro script, not even in encrypted form. Instead, during macro playback, when the macro runtime processes the Prompt action, the macro runtime pops up a window with an input field and a message prompting the end user to type an input key sequence. When the end user types the input key sequence and clicks OK, the macro runtime removes the popup window and directs the input key sequence into the session window at the specified row and column location.

Note: The default values for prompts are stored in macro files unencrypted. The default values display in the clear when you edit prompts in the macro editor. Therefore, while using a prompt to specify a password is an appropriate thing to do, for security reasons you should not specify a default value for the password.

Using an Input action does have this advantage, that the macro script runs automatically during macro playback without the end user having to intervene. However, if the confidential data changes (for example, if a password expires and a new and different password is required) then the Input action must be updated with the new input key sequence.