Reflections on WireGuard Design Goals
Reuben Martin
reuben.m.work at gmail.com
Sat Aug 11 01:07:56 CEST 2018
On Fri, Aug 10, 2018, 3:16 PM em12345 <em12345 at web.de> wrote:
> Hi,
>
> > From my point of view, the only thing which makes me uncomfortable about
> > wireguard is the lack of any second authentication factor. Your private
> > key is embedded in a plaintext file in your device (e.g. laptop), not
> > even protected with a passphrase.
>
> Most VPN authentications are just authorizing the machine and not the
> user sitting in front of that machine.
>
> > Anyone who gains access to that
> > laptop is able to establish wireguard connections.
> >
> > Of course, it can be argued that the laptop holds other information
> > which is more valuable that the wireguard key, therefore you should
> > concentrate on properly securing the laptop itself (*). Furthermore,
>
> No matter how much keys, passwords or tokens have to be entered by the
> user sitting in front of that machine, any other user already on that
> machine, will gain sooner or later access to the tunnel. This user or
> attacker doesn't even need to see/know wireguard's private key nor does
> the attacker need root access. Think of a second user logged in on that
> machine.
>
> It is definitely a bad idea to assume that the tunnel traffic of one
> "client" (in terms of wg's client key pair) comes from a specific user.
> Which also means that even multi factor VPN authentication still require
> all services inside the tunnel to ask for user authentication.
>
It should me noted that it is possible to isolate the VPN access to a
specific user if you assign login sessions to isolated network namespaces
and place the wireguard interface within the user's namespace.
-Reuben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180810/fd081a57/attachment-0001.html>
More information about the WireGuard
mailing list