### MCOP security considerations

Since MCOP servers will listen on a TCP port, potentially everybody (if you are on the internet) may try to connect MCOP services. Thus, it is important to authenticate clients.

#### The general function of the "md5auth" protocol

The md5-auth protocol does the following to ensure that only selected (trusted) clients may connect to a server:

- it assumes you can give every client a secret cookie
- every time a client connects, it verifies that this client knows that secret cookie, without actually transferring it (not even in a form that somebody listening to the network traffic could find it out)

##### The secret cookie

To give each client the secret cookie, MCOP will (normally) put it in the mcop directory (under /tmp/mcop-<username>/secret-cookie). Of course, you can copy it to other computers. However, if you do so, use a secure transfer mechanism, such as scp (from ssh).

##### Authentication of clients

The authentication of clients uses the following steps:

- [SERVER] generate a new (random) cookie R
- [SERVER] send it to the client
- [CLIENT] read the "secret cookie" S from a file
- [CLIENT] mangle the cookies R and S to a mangled cookie M using the MD5 algorithm
- [CLIENT] send M to the server
- [SERVER] verify that mangling R and S gives just the same thing as the cookie M received from the client. If yes, authentication is successful.

This algorithm should be secure, given that a) the secret cookies and random cookies are "random enough", and b) the MD5 hashing algorithm doesn't allow to find out the "original text", that is the secret cookie S and the random cookie R (which is known, anyway), from the mangled cookie M.

#### How it is implemented with the MCOP messages

The MCOP protocol will start every new connection with an authentication process. Basically, it looks like that.

- server sends a ServerHello message, which describes the known authentication protocols
- client sends a ClientHello message, which includes authentication info
- server sends an AuthAccept message

To see that the security actually works, we should look at how messages are processed on unauthenticated connections.

- Before the authentication succeeds, the server will not receive other messages from the connection. Instead, if the server for instance expects a "ClientHello" message, and gets an mcopInvocation message, it will drop the connection.
- If the client doesn't send a valid MCOP message at all (no MCOP magic in the message header) in the authentication phase, but something else, the connection is dropped.
- If the client tries to send a very very large message (> 4096 bytes in the authentication phase, the message size is truncated to 0 bytes, which will cause that it isn't accepted for authentication)

  This is to prevent unauthenticated clients from sending e.g. 100 megabytes of message, which would be received and could cause the server to run out of memory.

- If the client sends a corrupt ClientHello message (one, for which demarshalling fails), the connection is dropped.
- If the client send nothing at all, then a timeout should occur (to be implemented)

back to index