OpenVPN GUI Saved My Windows Password: Where It Lives

The connect dialog offers a checkbox to remember the login, and ticking it moves the account details out of the user's head and into the machine. The interface never says where. On Windows the candidates are the current user's registry area, a profile file that already carries the login, and whatever an automation script does. Each location has a different reader, a different failure mode and a different cleanup, so the useful question is which process can recover the secret and for how long. Follow the checkbox outward from the dialog, then decide what a lost laptop actually exposes.

Start With the Checkbox in the Connect Dialog

Remembered values are kept per profile and per Windows account, in the user hive rather than in a shared machine store. That is why a second user on the same computer sees no saved login, and why reinstalling the client does not necessarily clear the stored entry.

The profile file itself keeps the server, port and settings but no secret, which is why people inspect the wrong artefact first. Deleting the profile therefore removes the connection and leaves the credential behind. That is the most common surprise during cleanup. Remove both artefacts, not one.

What the Registry Value Reveals

The account name sits in readable text, so anything running as that user can decode it without any special call. The password is different: it is sealed with Windows DPAPI, bound to the account and, depending on the flags, to the specific machine. Lifting the sealed blob to another computer and replaying it therefore does not produce a usable secret.

Listing the values answers the operational question without touching the secret itself. Nothing needs to be decrypted to confirm an entry exists. The listing doubles as a before-and-after record for cleanup.

reg query "HKCU\Software\OpenVPN-GUI\configs" /s
cmdkey /list | findstr /i vpn
reg query "HKCU\Software\OpenVPN-GUI" /s | findstr /i "username password"

Two limits deserve to be stated plainly. A process inside the same logged-in session can call the same unprotect routine the client uses, so sealing is protection at rest rather than against a compromised desktop. And with no full-disk encryption, the sealed value is only as private as the disk.

When the Profile File Already Contains the Login

Some portals hand out a configuration with the account name and password written into it, so the client connects silently. At that point the file is a working credential, and every copy of it is another key to the same door.

Such files end up in backups, chat threads and synced folders, and none of those copies stops working when the original is deleted. Editing the local file changes nothing on the others. Revoking access means changing the password on the server, and doing it promptly. Cleanup on one laptop is a separate, smaller task.

Where a prompt is acceptable, prefer it and use the client's caching controls. If a pre-filled profile is genuinely required, keep it out of sync folders and remove it when the job ends.

Automation Moves the Secret Somewhere Else

Scripts introduce two more channels: process arguments and synthetic keystrokes. A file named on a command line is visible to anything that can read process arguments or the file's permissions, and a password typed by a tool goes to whatever window currently has focus. One published example types the desktop password that way before launching the client. A stored one-time-password seed deserves the same care, since it can generate every future code and outlives a single login.

The better pattern stores the secret where only the service account can read it, relies on the client documented retry and credential-source options, and avoids injected typing for privilege prompts. If the script needs the desktop password for elevation, that is a privilege design question rather than a VPN one.

Cleanup After a Lost Device

Revoke or disable the account on the server before anything else, because local deletion cannot invalidate a copy someone already has. Then clear the remembered registry values, remove the profile and any credential files, and search shell history and script directories for pasted passwords.

Write down what was removed and when access ended. That pair answers the only question an incident review asks: whether any copy of the credential still worked after the device left.