[cvsnt] Setting up shared repositories

Michael Wojcik Michael.Wojcik at microfocus.com
Thu Aug 16 15:05:31 BST 2007

> From: cvsnt-bounces at cvsnt.org 
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Tony Hoyle
> Sent: Thursday, 16 August, 2007 03:39
> Michael Wojcik wrote:
> > very real risk of password compromise.  (sspi is particularly bad 
> > because it requires use of the user's domain password; compromise 
> > exposes the user entirely.  If pserver and sserver are used with
> That's completely incorrect.  sspi uses the preexisting 
> windows authentication token.

If the local user isn't in the same domain as the server, then sspi
can't use the user's existing token - it's not valid on the server.
That's why "cvs login" works with sspi, and according to the CVSNT
documentation, CVSNT will still be storing the password locally:

After you enter the password, cvsnt verifies it with the server. If the
verification succeeds, then that combination of username, host,
repository, and password is permanently recorded, so future transactions
with that repository won't require you to run cvs login. (If
verification fails, cvsnt will exit complaining that the password was
incorrect, and nothing will be recorded.)

The records are stored, by default, in the file $HOME/.cvspass (Unix) or
the Registry (NT). The format human-readable, and to a degree
human-editable, but note that the passwords are not stored in
cleartext--they are trivially encoded to protect them from "innocent"
compromise (i.e., inadvertent viewing by a system administrator or other
non-malicious person).

CVSNT needs the password in plaintext to request a token in the server's
domain when sspi is used cross-domain - a common case with remote
workers.  If CVSNT can get it in plaintext, then an attacker running
with the same privilege as the CVSNT client (ie as the user) can get the
user's password in the server's domain from HKCU\Software\Cvsnt\cvspass.

The obfuscation algorithm is right in the CVSNT sources, so it's not
like it takes any effort to reverse it.  (It's not even salted, so even
without reversing it an attacker can see whether the user has different
passwords in different domains, if the user has logged in to
repositories in multiple domains.  And yes, I understand that improving
the obfuscation algorithm would break compatibility with other servers,
due to limitations in the pserver protocol.)

*That* is the exposure I was talking about.

>  In any modern configuration 
> that's passing kerberos tokens (and encrypted SSPI is fully 
> encrypted kerberos which is basically uncrackable).  Even 
> NTLMv2 is pretty nontrivial to crack over the wire.

Since I wasn't talking about cracking it on the wire, that's irrelevant.

> For sserver by default it uses self signed certificates which 
> is perfectly fine for the purpose (which is to stop the 
> trivially encrypted pserver passwords going over the wire in 
> readable form).

That "purpose" is fine if your threat model stops at passive snooping.
I was talking about server-impersonation attacks, which self-signed
certs do nothing to prevent.

> You can enable strict checking on the client but if you do 
> that you must have a proper signed certificate on the server 
> recognised by a CA listed in ca.pem (which you can replace 
> with your own if you like).  That's an advanced configuration 
> - most people don't do that.

In which case the advantage of sserver over pserver (which is what
started this whole subthread) is that it provides some protection
against casual passive snooping attacks.  Sure, that fits some people's
threat models (usually implicit threat models, since it's unlikely most
of those people have done any security analysis at all).  But pserver
already provides some trivial "honest user" protection against snooping,
by obscuring the passwords; sserver adds little security on top of that.

Michael Wojcik
Principal Software Systems Developer, Micro Focus

More information about the cvsnt mailing list