-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security concerns (general) #22
Comments
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. |
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. |
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.
If the config gets lost, just regenerate the peer config with a new keypair. |
Interesting. |
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.
The text was updated successfully, but these errors were encountered: