xpra icon
Bug tracker and wiki

Changes between Version 32 and Version 33 of Authentication


Ignore:
Timestamp:
12/30/17 10:02:15 (12 months ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Authentication

    v32 v33  
    2020{{{#!div class="box"
    2121== Modules ==
    22 The authentication module used is specified using
     22The authentication modules used are specified using
    2323* {{{--auth=MODULE}}} for unix domain sockets and named pipes
    2424* {{{--tcp-auth=MODULE}}} for TCP sockets
    2525* {{{--vsock-auth=MODULE}}} for vsock (#983)
     26etc
     27
     28With version 2.3 and later, you may specify more than one module.
     29ie: {{{--tcp-auth=hosts --tcp-auth=sqlite}}} will verify "TCP Wrappers" before checking the sqlite database. (see #1728 for details)
    2630
    2731[[BR]]
     
    4145||[/browser/xpra/trunk/src/xpra/server/auth/sqlite_auth.py sqlite]||sqlite database authentication||see ticket:1488#comment:37 || >=2.1||
    4246||[/browser/xpra/trunk/src/xpra/server/auth/peercred_auth.py peercred]||SO_PEERCRED authentication||see r15886 || >=2.1||
     47||[/browser/xpra/trunk/src/xpra/server/auth/hosts_auth.py peercred]||[https://en.wikipedia.org/wiki/TCP_Wrapper TCP Wrapper]||see #1730 || >=2.3||
    4348}}}
    4449
     
    6570"file" vs "multifile":
    6671* "file" contains a single password, the whole file is the password
    67 * "multifile" contains a list of authentication values, see [/ProxyServer#FileAuthenticationExtras proxy server file authentication].
     72* "multifile" contains a list of authentication values, see [/ProxyServer#FileAuthenticationExtras proxy server file authentication] - this module is deprecated in favour of "sqlite" which is easier to configure.
    6873}}}
    6974
     
    9297* All clients first send a ''hello'' packet to the server. If the client expects the server to request authentication for the connection, the client packet may omit most of the regular configuration information since a second packet will need to be sent. Until the server accepts the connection with its own ''hello'' packet response, the only packets that will be accepted by the clients are ''challenge'' and ''set_deflate'' (used to control packet compression). The client will exit unless the server responds within the {{{XPRA_SOCKET_TIMEOUT}}} delay + 10 seconds.
    9398* The server sends back a ''challenge'' packet containing a random salt and the digest method to use as specified by the authentication module. If the client does not respond within the {{{XPRA_SOCKET_TIMEOUT}}} delay (defaults to 10 seconds), it is disconnected. The only packets that will be accepted by the server until the client has successfully authenticated are ''hello'' and ''disconnect''.
    94 * The client generates its own random salt and responds with a new "hello" packet containing the challenge response (the hashed password and the client salt used), the client and server salts are combined with "xor" before hashing the password. (so there is no way for the server to predict the actual salt used at all)
     99* The client generates its own random salt and responds with a new "hello" packet containing the challenge response (the hashed password and the client salt used), the client and server salts are combined before hashing the password. (so there is no way for the server or client to predict the actual salt used)
    95100* When the server receives the ''hello'' packet containing the challenge response, it hands it over to the authentication module, which can then:
    96101 * with ''hmac'': verify that it obtains the same hash by combining its own password value with the two salts
    97102 * with ''xor'': xor the password again with the two salts to retrieve the original password value
     103* these steps may be repeated if there is more than one authentication module configured (though not all authentication modules require a challenge exchange)
    98104}}}
    99105