xpra icon
Bug tracker and wiki

Changes between Version 18 and Version 19 of Authentication


Ignore:
Timestamp:
11/14/15 09:19:14 (5 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Authentication

    v18 v19  
    4141}}}
    4242
     43
     44{{{#!div class="box"
     45== Authentication Process ==
     46
     47The steps below assume that the client and server have been configured to use authentication:
     48* If the server is not configured for authentication, the client connection should be accepted but a warning will be printed
     49* If the client is not configured for authentication, the connection will fail with an authentication error
     50
     51Notes:
     52* This information applies to all clients: regular GUI clients as well as command line clients like "xpra info"
     53* Each authentication module specifies the type of password hashing it supports (usually [https://en.wikipedia.org/wiki/Hash-based_message_authentication_code HMAC])
     54* The "sys" authentication modules (pam and win32) require the actual password to be sent across to perform the authentication on the server - they therefore use the weak "xor" hashing
     55* You must use [/wiki/Encryption] to be able to use "xor" hashing so that the password is protected during the exchange: the system will refuse to send "xor" hashed password unencrypted
     56* Encryption is processed before authentication
     57
     58For more information on packets, see [/wiki/NetworkProtocol].
     59
     60Negotiation:
     61* 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.
     62* 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''.
     63* 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)
     64* When the server receives the ''hello'' packet containing the challenge response, it hands it over to the authentication module, which can then:
     65 * with ''hmac'': verify that it obtains the same hash by combining its own password value with the two salts
     66 * with ''xor'': xor the password again with the two salts to retrieve the original password value
     67}}}
     68
     69
    4370{{{#!div class="box"
    4471== Security Considerations ==
    4572
    46 * the password is never sent in plain text over the wire, the authentication modes that require the password to be sent to the server unhashed ({{{sys}}}: {{{pam}}} and {{{win32}}}) will refuse to run without [/wiki/Encryption Encryption]
    4773* when used over TCP sockets, password authentication is vulnerable to man-in-the-middle attacks where an attacker could intercept the initial exchange and use the stolen authentication challenge response to access the session, [/wiki/Encryption Encryption] prevents that
    4874* the client does not verify the authenticity of the server, [/wiki/Encryption Encryption] does
     75* Enabling {{{auth}}} [/wiki/Logging] may leak some authentication information
    4976}}}