How to share database credentials securely
The staging password doesn't belong in Slack.
The problem
A new developer joins the team. They need the staging database password. Someone pastes it into a Slack DM. The developer copies it, sets up their local environment, and moves on. The password stays in the DM. A month later it's in the workspace search index. Six months later it's in a compliance export. The developer who originally needed it has long since saved it locally, but the copy in Slack is still there, accessible to anyone who can search the workspace.
Connection strings are worse. They often contain the host, the port, the username, and the password in a single line. One message in Slack and someone has everything they need to connect.
Why database credentials are different
A leaked WiFi password gives someone network access. A leaked database password gives someone access to your data. Staging databases often contain copies of production data, sometimes with real customer records. A connection string in a Slack export is a direct line to that data.
Most teams rotate database passwords less often than they should. The staging password that was sent over Slack in January is probably still valid in August.
How to share database credentials with Secret.Broker
1 Go to the tool and paste the database password or the full connection string. Your browser encrypts it before sending anything to the server.
2 Set the view limit to 1 for a single developer. If multiple people need the same credentials, set it to match. Choose a short expiry. An hour is enough if they're online. A day if they're in a different timezone.
3 Copy the link and send it over Slack, Teams, or email. Label it clearly in the message: "Staging DB password" or "Connection string for the reporting database." The label goes in the message. The credentials stay behind the encrypted link.
4 The developer opens the link, copies the credentials into their local config or password manager, and the encrypted data is hard-deleted from the server. The Slack message now contains a dead link.
For developer onboarding
Day one usually involves multiple database credentials: staging, development, maybe a read replica or a reporting database. Create a separate secret for each one. Set view limits to 1 and expiry to 24 hours. Send the links with clear labels. The new developer opens each link, saves the credentials, and the links go dead.
If you're also sharing API keys and .env files, see the onboarding credentials guide for the full workflow.
For contractor handoffs
A contractor needs access to your staging database for the duration of a project. Send the credentials through a one-time link. When the project ends, rotate the password. The link is already dead, and if you've rotated the password, the credential the contractor saved locally is also useless.
See sharing credentials with contractors for more on managing credential lifecycles across engagements.
This is not a secrets manager
If your team needs ongoing shared access to database credentials, use a secrets manager like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Those tools handle rotation, access control, and audit trails.
This handles the handoff. You have a database password that needs to get from one developer to another right now. After that, it shouldn't exist anywhere except where it's actually used.
What the encryption does
Your browser encrypts the credentials on your device before anything goes to the server. The server stores ciphertext it can't read. The protocol page covers the full details: XChaCha20-Poly1305 encryption and why I never have the key.