Why You Shouldn’t Use the Same WireGuard Key on Multiple Clients
When you’re setting up a new WireGuard VPN (Virtual Private Network), you might ask yourself “Can I use the same WireGuard key for multiple clients?”, or “Can’t I just distribute the same WireGuard configuration file to everyone in the same group?” There are two big reasons why you shouldn’t:
- It’s bad security practice
- It will result in a bad user experience
Bad Security Practice
Sharing WireGuard keys is bad for the same reasons that sharing accounts generally is bad — it causes problems with:
- Audit trails
- Access control
- Secret rotation
Audit trails
When you share keys (or accounts), you can never be sure exactly who performed what action. Was it Alice or Bob or someone else who accessed this file or deleted this record? Not knowing prevents you from being able to hold someone accountable for mischief, malice, or just plain incompetence.
For many businesses, being able to connect a specific action to a specific person through your audit logs is a legal or other compliance requirement. If your audit logs don’t have traceability to an individual person or identity, they’re probably failing at their intended purpose (be it to comply with regulations, enable intrusion detection, allow the investigation of security or performance incidents, or facilitate the analysis of system telemetry or other metrics).
Access control
Sharing keys or accounts also hampers effective access control. It prevents you from applying more restrictive access to different individuals who have access to the shared key/account, thwarting the Principle of Least Privilege.
For example, say you give your full team access to all your production applications through a shared WireGuard key, even though team member Alice only needs access to application A, and team member Bob only needs access to application B. With the shared key, you can’t restrict Alice’s (unneeded) access to application B without also restricting Bob’s (needed) access to it; and you can’t restrict Bob’s (unneeded) access to application A without also restricting Alice’s (needed) access to it.
Sharing keys also makes it hard to make changes to existing access control policies in response to business changes. For example, if originally both Alice and Bob both needed access to both application A and application B, you might be tempted to let them share a key that granted access to both applications. But if a business change requires you to cut off Bob’s access to application A (like Bob is moved into a division that legally can’t have access to application A), you can’t do that with the shared key.
Secret rotation
Sharing keys/accounts also makes key rotation a headache. You have to coordinate the rotation among all the different parties who have access to the key, to make sure no one gets locked out or has their usual duties interrupted at a critical moment.
And sharing keys means rotation will be even more frequent than usual — not only will you have to comply with your usual secret-rotation schedule, but you’ll also have to rotate keys every time any one with access to the key has a potential account compromise, or malware infestation, or laptop stolen, or is reassigned to a different position, or has their department reorganized, or leaves your company, etc.
Bad User Experience
WireGuard was designed to prevent misuse from bad security practices — so if you try to use the same key for multiple clients, you’re in for a bad experience. WireGuard assumes each distinct client (aka peer) will use a distinct cryptographic key pair. The public key in this key pair is not only used to establish an encrypted connection with the peer — it’s also used as a unique identifier for the peer.
WireGuard, in fact, uses a peer’s public key as the lookup key in its internal table of connected peers; when sending encrypted traffic to a peer, WireGuard consults this table to determine the public IP address and port (aka endpoint) to which it should send the encrypted traffic. If more than one endpoint tries to use the same key at the same time, the entry in this table for other endpoints trying to use the same key will be overwritten with the last endpoint to use the key.
When only one user is actively using a key, nothing will appear amiss — but when more than one user tries to connect to the same WireGuard host with the same key at the same time, the experience for all users will go bad — their connection will appear to “freeze” or “hang” until all but one user gives up. Behind the scenes, WireGuard will be sending most packets back to the wrong endpoint most of the time, resulting in missed responses and constant retries by the applications those users are trying to use through WireGuard.
Best Practices
The best practices for WireGuard keys are similar to those for SSH keys or client certificates (or any other host-based credentials) — no two hosts should share the same key (even for hosts that are considered simple “clients”). While this takes a little more work to set up, it’s much more maintainable in the long run.
Additionally, if you operate more than one WireGuard interface on an individual host, it’s an okay practice to use the same key for all the interfaces on the host (it won’t result in a bad user experience) — but the best practice is to use a different key for each individual interface. The same security-practice issues described above also apply when sharing keys among interfaces on the same host (albeit to a lesser degree) — so not sharing keys makes for better/easier auditability, access control, and key rotation.