When a client connects to an svnserve process, the following things happen:
The client selects a specific repository.
The server processes the repository’s conf/svnserve.conf file and begins to enforce any authentication and authorization policies it describes.
Depending on the defined policies, one of the following may occur:
The client may be allowed to make requests anonymously, without ever receiving an authentication challenge.
The client may be challenged for authentication at any time.
If operating in tunnel mode, the client will declare itself to be already externally authenticated (typically by SSH).
The svnserve server, by default, knows only how to send a CRAM-MD5 authentication challenge. In essence, the server sends a small amount of data to the client. The client uses the MD5 hash algorithm to create a fingerprint of the data and password combined, and then sends the fingerprint as a response. The server performs the same computation with the stored password to verify that the result is identical. At no point does the actual password travel over the network.
If your svnserve server was built with SASL support, it not only knows how to send CRAM-MD5 challenges, but also likely knows a whole host of other authentication mechanisms. See Using svnserve with SASL to learn how to configure SASL authentication and encryption.
It’s also possible, of course, for the client to be externally authenticated via a tunnel agent, such as ssh. In ...