Re: The git protocol and DoS

From: David Brown <git@davidb.org>
Date: Oct 20, 2005, 00:20 UTC
Message-ID: <20051020002040.GA30232@old.davidb.org>
In-Reply-To: <20051019222044.GP30889@pasky.or.cz>

On Thu, Oct 20, 2005 at 12:20:44AM +0200, Petr Baudis wrote:

Show 16 quoted lines

>   If (well, it sounds like a good idea, so rather "when") you do this,
> it would be a good idea to do in a way that makes it easy to later add
> support for some kind of authentication (really, not everyone wants to
> give away ssh accounts). Let's say it works like:
> 
> [client]	git-upload-pack <path>
> [server]	challenge somethingnonsensical
> [client]	challenge-response <username>:sha1(somethingnonsensical<password>)
> [server]	All right, the pack goes like this...
> 
>   Suddenly you have support for hopefully secure authentication, and at
> the same time you have the cookie implemented in backwards-compatible
> fashion (in the sense that new client will be able to talk to old
> server) - just assume the username and password empty. This might be
> even hardcoded for now, just leave a room for its addition (in an
> elegant and compatible way) in the protocol, please.

This kind of password authentication has several problems that make it fairly unpractical. It is prone to easy dictionary attacks for one thing. It also for a spoofed server to do replays, and the likes. It also requires the server to store plaintext passwords.

There are other, much better, authentication algorithms, but short of doing signatures, none are really much more secure. The closest you'll get to secure remote passwords is SRP <http://srp.stanford.edu/>, which is quite good, and doesn't even require plaintext passwords to be stored. It might just be easier at that point to use signatures, though.

Dave