Xpra: Ticket #1789: U2F authentication support

Fri, 23 Mar 2018 12:27:12 GMT - Antoine Martin: status changed

status changed from new to assigned

Initial support added in r18801.

To use it:

It will print the public key and the key handle, both need to be preserved. The public key is stored on the server, the key handle is used on the client to tell libu2f which key to use for authentication.

start the server with the public key:

xpra start --start-child="xterm" --bind-tcp=0.0.0.0:10000 -d auth \
    --tcp-auth=u2f,public_key=041438f9c6cb2b6dec3a86e3b9eb7afe77112c817a371a9b0b74988619cf5f5b06b8211a4082818940de564aca8ac7dfecf34d23187b42340a261891c637cba794

run the client with the matching key signature:

XPRA_U2F_KEY_HANDLE=ebecec9d7665dec1e1c6261ede6ad7ba2556a07be705c4bff399b3acf37e00a6e82b26ebbb759418be22fa8bbbec6ac1c0007257d23550e63fdbf2853259499e \
    xpra attach tcp://localhost:10000 -d auth

And activate the U2F key when requested (ie: when it blinks).

Still TODO:

package pyu2f?
build and test on macos and win32
support loading the public key per user so it can be used with the proxy (ie: ~/.xpra/u2f.hex?) and maybe support other key storage formats than hex?
better way to specify the key handle on the client, per server? (also from file)

There are other libraries we can use to interface with u2f, but they're not as nice, ie: python-u2flib-host.

Fri, 23 Mar 2018 12:27:48 GMT - Antoine Martin: attachment set

attachment set to u2f_auth.py

example of all in one registration + authentication using pyu2f

Fri, 23 Mar 2018 12:29:55 GMT - Antoine Martin: attachment set

attachment set to u2flib_auth.py

alternative example using u2flib_host

Sat, 24 Mar 2018 09:51:48 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to J. Max Mena
status changed from assigned to new

Updates:

macos and rpm packaging: r18802, r18813
macos bundling: r18808 (+r18839 for python2 builds)
win32 packaging: r18807
minor fixups: r18803 + r18804, r18805, r18806, r18817, r18818
better debug logging: r18811, r18812
load key signature and public key(s) from files: r18815
utility script / GUI for registering and creating those files: r18816

Although we still support environment variables for specifying the key-handle and the public key, the preferred way is to store them as hexadecimal files in the application's user configuration directory (ie: .xpra on posix). Running the new browser/xpra/trunk/src/xpra/client/gtk_base/u2f_tool.py will create two files there:

u2f-keyhandle.hex containing the key handle used by the client for talking to the U2F device. This file may be renamed to u2f-keyhandle-HOSTNAME.hex (ie: u2f-keyhandle-example.com.hex which will be used when connecting to example.com server only, ie: xpra attach ssh://example.com/) - note: we only try the first valid key handle we find.
u2f-pub.hex which contains the public key matching the key handle. This file can be renamed (ie: u2f-pub-myusername.hex) and the server will try to load every file matching u2f-pub*.hex, accepting the authentication as soon as one public key validates the signature successfully)

Testing locally with an $18 FIDO U2F Security Key:

run the u2f_tool

start the server:

xpra start --start-child="xterm" --bind-tcp=0.0.0.0:10000 --tcp-auth=u2f -d auth

connect with the client (activating the U2F device when requested, ie: when it blinks):
```
xpra attach tcp://127.0.0.1:10000 -d auth
```

To test using a remote client machine (ie: already tested with a linux, win32 and macos as both clients and servers):

run the u2f_tool on the new client system,
copy the resulting u2f-pub.hex to the user configuration directory on the server (ie: ~/.xpra)
attach (and again, activate when requested)

Future enhancements:

we should verify the counter for each key (hard: need to store it on the server filesystem), see U2Fishing
store / read the keys from ~/.config/Yubico/u2f_keys like pam-u2f does?
support the global Central authorization mapping?
store the key-handle with the public key? (then the server could tell the user which key-handles to try)
html5 support: #1843

Fri, 01 Jun 2018 11:47:01 GMT - Antoine Martin: status changed; resolution set

status changed from new to closed
resolution set to worksforme

Sat, 23 Jan 2021 05:33:50 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1789