Security concerns (general)

[stefanoco]

This project is really nice. This and other similar workflows pose a security concern that I'd like to be discussed here if possible: the generated configuration exhibited with a QR code or contained in a file to be moved to the peer contains everything is needed in order to be recognized as a valid peer.

Robust best practices would require that secrets be distributed following min two separate paths, and (even better) Wireguard was designed in a way that enables a peer to generate its own keys pair and send back to the server only the public part.

I understand this is a bit mor complicated as a process but I'm asking myself if I'm the only one concerned about this.

[vx3r]

Hi @stefanoco. IMHO if you want to connect to the server you basically trust the server, even if your point is completely legitimate I think it’s a overkill to ask to a no technical user to provide a public key, download the configuration and put his own private key in order to be able to connect. Plus to be able to generate a QR code the user need to provide the private key or edited configuration file, too complicated I believe. I can always add the option to delete client private key after the initial download. Letting the issue open if more users are concerned

[Shachindra]

Interesting Point. We could have this functionality to generate the private & public keys on the browser (or even ask user to input the public key) and send only the public key part to the server.

Its helpful in case this is deployed in an environment where everyone has access to the Dashboard and you don't want other users to connect to the server using your profile. But of course you lose the QR code generating functionality and also the onus falls on the user to manage the conf file.

[sk-gara]

I think there should be an option to get rid of the clients private key after generating a new peer config. Aside from keeping the ability to generate the QR there is no need to keep it. The workflow as i imagine:

• add peer (ideally with an IP from a certain range, like .100 and upwards or just type in the exact IP)
• conf file (and QR if needed) is generated and either put in a directory or directly downloaded
• send conf file to customer/client

If the config gets lost, just regenerate the peer config with a new keypair. Anything I missed?

[calee0219]

Interesting. I'm also thinking about adding a option to let client provide their public only as an option. In this situation, maybe it can generate an QRcode without PrivateKey= and due to the client using this option, they may know how to fill in the blank.