Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> 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