Changes between Version 18 and Version 19 of Authentication

Timestamp:

11/14/15 09:19:14 (5 years ago)

Author:

Antoine Martin

Comment:

--

Authentication

@@ -41 +41 @@
 }}}
 
+
+{{{#!div class="box"
+== Authentication Process ==
+
+The steps below assume that the client and server have been configured to use authentication:
+* If the server is not configured for authentication, the client connection should be accepted but a warning will be printed
+* If the client is not configured for authentication, the connection will fail with an authentication error
+
+Notes:
+* This information applies to all clients: regular GUI clients as well as command line clients like "xpra info"
+* Each authentication module specifies the type of password hashing it supports (usually [https://en.wikipedia.org/wiki/Hash-based_message_authentication_code HMAC])
+* 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
+* 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
+* Encryption is processed before authentication
+
+For more information on packets, see [/wiki/NetworkProtocol].
+
+Negotiation:
+* 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.
+* 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''.
+* 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)
+* When the server receives the ''hello'' packet containing the challenge response, it hands it over to the authentication module, which can then:
+ * with ''hmac'': verify that it obtains the same hash by combining its own password value with the two salts
+ * with ''xor'': xor the password again with the two salts to retrieve the original password value
+}}}
+
+
 {{{#!div class="box"
 == Security Considerations ==
 
-* 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]
 * 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
 * the client does not verify the authenticity of the server, [/wiki/Encryption Encryption] does
+* Enabling {{{auth}}} [/wiki/Logging] may leak some authentication information
 }}}