When a script is created in the portal, the contents of the script (and other associated configuration data) are transferred to the Catchpoint servers encrypted via HTTPS. They are stored encrypted at rest in the Catchpoint database. When a test needs to be sent to a node, the data is transferred to the node encrypted, then the node decrypts the data in-memory, and performs the test. Once the test is completed, the data is removed from the memory of the node until the next time this test needs to be run.
As described above, all the test data, including hard-coded credentials are encrypted as soon as they are submitted from the portal, but are decrypted again to display the transaction script to the portal user. If you would like to have additional protection where this data is not visible by anyone, we offer the use of a special macro: ${password}. When this macro is used, the transmission and storage of the data are exactly the same – except that it is never displayed back to the UI.
On the new test page, a field is present in the UI for storing the password in an encrypted state. The password is stored in two components, namely its encrypted value and its encryption key. Calling the macro “${password}” causes us to decrypt the password as per its encrypted password value & key information.
Those encryption fields are stored as an array of bytes when passed to the Agent, so they too are not readable over the wire. The username and password could be stored this way together, and then split apart on the execution of the script if the username should be secured.
Below is an example transaction to split the username and password when they are stored together.
// Step - 1 var foo = ${password} open("www.example.com") type("//input[@id='username']", "${var(foo, left(8))}") type("//input[@id='password']", "${var(foo, right(8))}") // Step - 2 clickAndWait("//*[@id='login']")
To extract the username, the transaction uses sub macro left to grab the eight leftmost characters, and to extract the password it uses sub macro right to grab the eight rightmost characters. For this example, the username and password stored in the UI were eight characters each.
When the password macro is used, the password is scrubbed from any captured request and response headers and body. The original password will appear in the capture data as *********.
The data between the scheduling system and the agent is transmitted using a custom binary data format. The password is included in the binary format using a symmetrical key algorithm. Symmetric-key algorithms are algorithms for cryptography that use the same cryptographic keys for both encryptions of plaintext and decryption of ciphertext. As we deploy the software globally, we need to comply with US government laws for any encryption technology and the keys we use.
Please note, the authentication settings as described by the UI will still be applied to requests. All relevant headers, string manipulations, and encoding will still be performed on requests independent of the macros. It is recommended to use NTLM if this is not desired.