Paul Koning wrote:
>>>>>>"Jim" == Jim Correia <jim.correia@pobox.com> writes:
>
>
> Jim> On Nov 11, 2005, at 11:10 AM, Leon Zandman wrote:
> >> I think it would be better to not store passwords, but only their
> >> hashes
Yes. Me too.
> Jim> In order to not send the cleartext password (or re-usable token,
> Jim> which would be equivalent) over the network, svnserve needs the
> Jim> local password in cleartext. (The current implementation uses
> Jim> cram-md5 challenge response.)
Why not working with the hashes? This would be very simple, e.g. like
(say, the username is "joesoap" and the password is "P@$$W0RD"):
On the server:
The admin uses ' echo "joesoap:P@$$W0RD" | md5sum' (note the space in
front of the "echo", to avoid that line to end up in the history ;))
and writes the entry "joesoap = 810e10f172761eadf24d623396559589" into
the passwd file of the repository. Done.
No change needed for the subversion server at all.
The client, however, would need a change, to do the following:
Whenever the server requests a password (by sending a challenge to fit
"810e10f172761eadf24d623396559589", because it believes that this is
the password of joesoap), The client asks the user for the password. At
this point, the client already knows that username is "joesoap" because
the user tried to contact the svnserver with that username. The user
enters "P@$$W0RD". Now the client combines this to "joesoap:P@$$W0RD"
and calculates the md5sum for it. Then it fulfills the challenge with
the result of the calculation instead of the real password.
As I said, very simple. It is by no means any more secure than just
using the plaintext passwords (or maybe a wee bit, because it will
take some time to find a password that results in the same md5 value
when combined with the username and a colon, but to find it is just a
matter of time) - but: the user's password does not need to be stored
in a well-known place in the repository any more.
> There are ways to avoid that, as in SRP for example. Then again,
> there are patent issues that make that problematic for GPL code...
>
> paul
There are all sorts of improvements possible to my idea, it is just
meant as a "kickstart" for thinking about it (yes I know this has been
tried before...) and I'm quite sure that my idea is not patented.
At least, I didn't do it and now that it is out in the open, prior art
applies :)
Any comments?
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 15 21:59:24 2005