Secure Credentials

CheckView’s Secure Credentials feature lets you store encrypted login credentials (username and password) for test flows that require authentication. Rather than hardcoding sensitive values directly in test steps, credentials are encrypted at rest and injected at runtime — keeping them out of step configurations, logs, and the UI.

Why Use Secure Credentials?

Encryption at rest: Credentials are encrypted with AES-256-GCM using organization-specific keys stored in Google Cloud Secret Manager. They are never stored in plain text.
Not visible in step configuration: When a step uses a stored credential, the value field is disabled and shows only a placeholder — the actual credential never appears in the step editor.
Per-organization isolation: Each organization has its own unique encryption key. Credentials from one organization cannot be decrypted by another.
Team-safe: Team members with access to the test flow can run tests that use stored credentials without ever seeing the actual password.

Step 1: Configure Credentials in Test Flow Settings

Before you can use secure credentials in test steps, you need to store them in the test flow’s settings.

Open the test flow you want to configure.
Go to Settings → Advanced.
Scroll to the Test Account Credentials section.
Click Add Credentials.
Fill in the form:
- Username — The login username or email (e.g., [email protected]).
- Password — The account password. This field is masked and will be encrypted before saving.
- Description (optional) — A label to help you remember which account this is (e.g., “QA test account”).
Click Save Credentials.

Once saved, the section will show “Credentials configured” with a green Encrypted badge, confirming that your credentials are securely stored.

You can update or remove credentials at any time from this section. Note that updating credentials replaces them entirely — the previous values cannot be recovered.

Step 2: Apply Credentials to Assign Steps

After storing credentials, you can link individual assign steps to use them at runtime.

Open the test flow’s Step Editor.
Select (or create) an Assign step that targets a login field — for example, a username input or password field.
In the step’s settings, find the “Use stored credential” dropdown.
Select the appropriate option:
- None — The step uses its regular value (default behavior).
- Username — The step will use the stored username credential at runtime.
- Password — The step will use the stored password credential at runtime.

When you select Username or Password, the step’s Value field becomes disabled and displays: “Will use stored [username/password] at runtime.” A blue info box also appears confirming that the credential will be securely retrieved during test execution.

How It Works at Runtime

When a test runs, CheckView handles secure credentials automatically:

The test executor retrieves and decrypts the stored credentials for the test flow.
When the test reaches an assign step marked with “Use stored credential,” the decrypted value replaces the step’s empty value field.
The credential is filled into the form field on the page, just like any other assign step.
If no credentials are found (e.g., they were removed), the step falls back to its configured value field.

Temporary Credentials via API

When triggering a test run via the CheckView API, you can pass one-time credentials that override the stored credentials for that specific run. These temporary credentials are:

Encrypted using the same AES-256-GCM encryption as stored credentials.
Short-lived — they expire automatically after 5 minutes.
Single-use — they are deleted immediately after the test retrieves them.
Higher priority — if both temporary and stored credentials exist, the temporary credentials are used.

This is useful for CI/CD pipelines or automated workflows where credentials may change per environment or run.

Security Details

Encryption: AES-256-GCM — a FIPS 140-2 compliant authenticated encryption standard.
Key storage: Organization-specific encryption keys are stored in Google Cloud Secret Manager, not in the application database or environment variables.
Field-level encryption: The username and password are encrypted separately, each with their own initialization vector (IV) and authentication tag.
Access control: Only authenticated team members with access to the website can manage credentials. Organization ID is verified on every retrieval.
Cascade deletion: Credentials are automatically deleted when the associated test flow is deleted.

Common Questions

Can team members see stored credentials?

No. Once saved, credentials are encrypted and cannot be viewed by anyone — including organization admins. Team members can run tests that use stored credentials without seeing the actual values. To change a credential, you must replace it entirely.

Do credentials appear in test recordings or screenshots?

Credentials are filled into form fields during test execution, so the values may be visible in screenshots and video recordings (for example, a username typed into a login form). These test artifacts are stored securely and are only accessible to authorized team members. For password fields, most websites mask the input automatically.

What happens if I remove credentials after steps are configured to use them?

Assign steps marked with “Use stored credential” will fall back to their configured value field. Since the value field is typically empty when using secure credentials, the step will fill an empty string — which will likely cause the test to fail. Update or remove the “Use stored credential” setting on affected steps if you remove credentials.

Can I use secure credentials with non-login forms?

The credential fields are “Username” and “Password,” designed for login scenarios. However, you can store any pair of sensitive values — for example, an API key in the username field and a secret token in the password field. The labels are just conventions; any text value can be stored.

Test Flow Advanced Settings