Sending Client Credentials to Your Password Manager

When a client sends credentials for an engagement, the tester sees them once, in the one-time view, before they are deleted. With your password manager set up, that view has a Send to button for it. 1Password, Bitwarden, Passbolt and Keeper are connected once by an administrator and sent to from your own gateway, so a tester presses the button and nothing else. KeePass and KeePassXC are written straight into the tester’s own file, and HashiCorp Vault and the others take them from the tester’s own browser, so a manager that answers only your office’s or your VPN’s addresses still takes them. None of it passes through Pental.

Set it up

1. An administrator opens Settings, Integrations, and under Password managers presses Add a password manager.
2. Choose the manager and how it gets there. Each manager is offered the ways it takes, the safest first.
3. Name its button, give anything its way needs (below) and press Add. Up to twelve can be set up, and a tester chooses among them.

Connected once: 1Password, Bitwarden, Passbolt and Keeper

Each is connected as an account of Pental’s own in the manager, made for it and given only the vault, collection or folder the credentials go in. Its details are kept in your database, encrypted with your own key, and read only by your gateway as it sends. The gateway writes each item with the manager’s own software, so the manager encrypts it as it encrypts everything, and says how each one went as it lands.

Press Connect. Your gateway signs in and says who Pental is there and where it can put things, and you choose the vault, collection or folder. Each item goes in a folder for the client and the assessment where the manager keeps folders, and a Passbolt item is shared as its folder is, and with a group where you choose one.

Sending from your gateway needs your database behind a Pental gateway, 1.14.0 or later. With your database on Supabase, choose another way for these four.

KeePass or KeePassXC

Each tester chooses their own KeePass file once, in Chrome or Edge, which remember it for them. When they send, they give its master password and the items are written straight into it, in a folder for the client and the assessment, with their one-time codes, their secret values and their files. The file stays on their computer, and one changed while it is written to is left as it is.

HashiCorp Vault

Give its address (https, the one your team’s browsers use), the KV engine’s path (secret, unless yours is elsewhere) and its version. Each tester sends with their own Vault token, and you choose whether it is kept on their device, sealed in their browser for them and that Vault as you set it up (change anything about it here and the token is asked for again), or asked for once a session and never kept.

Vault has to let the portal’s address call it from a browser, which is its CORS setting; the form shows the line to run, vault write sys/config/cors enabled=true allowed_origins= and your portal’s address. A tester’s token needs only to create and update under the folder the items go in, such as path "secret/data/pental/*" { capabilities = ["create", "update"] }. Nothing already in Vault is written over: on KV 2 an item whose name is taken gets the next free one, and on KV 1 each name ends with a few letters of its own.

1Password

The Save in 1Password button is 1Password’s own. Each item gets one, and pressing it opens 1Password, which asks which vault it goes in. Testers need the 1Password extension installed and unlocked; until then the buttons stay grey, and the panel says why. 1Password sets an item’s website to the portal’s address, so the address to sign in at is in the item’s notes.

To send to one vault without asking, add your 1Password Connect server as an API instead, from its ready-made request: put your server’s address and the vault’s ID in place of the examples, and each tester sends with their own Connect token. The server has to allow the portal’s address, usually a line in the proxy in front of it. In any request you describe, only {{title}}, {{folder}}, {{client}}, {{assessment}} and {{type}} can go in its address, since an address ends up in logs; passwords and notes go in the body, and the token in a header.

The encrypted file

For a manager not connected, and for KeePass in a browser that cannot write to a file in place, the tester’s browser makes an encrypted KeePass file (KDBX 3.1, AES-256) holding every item, with the client’s files attached, and shows its passphrase once. The passphrase is kept nowhere, and without it the file cannot be opened. The panel gives the manager’s own steps for importing it, such as Bitwarden’s Import data with the file format KeePass (kdbx).

Names and folders

Each item is called starts as {client} - {assessment} - {name} and In the folder as Pental/{client}/{assessment}, where {name} is the login’s role, or what the client called it. {type}, {username} and {date} work too, and a / makes a folder inside a folder: a group in the KeePass file, a path in Vault.

Sending

1. The tester opens View & Copy Credentials on the engagement. Under the one-time warning, Send to has a button for each manager set up.
2. They choose one. Its panel lists every item, ticked: each login, an API key, an SSH key, a certificate, the files.
3. For a connected manager, that is all: every item goes from your gateway, and each says where it landed, or why not. For KeePass they give the file’s master password; for Vault or an API, their own token the first time, then Send. For a file, they download it and import it.
4. The engagement’s timeline records what went where, with nothing secret in it. When they confirm, the credentials are deleted as before, and files already sent with their item count as saved.

Passwords, keys and files go from your gateway or the tester’s browser to the manager, so Pental’s servers never see them. Security sets out what they can and cannot reach.