Scott Palmer wrote:
>
> On 15-Nov-05, at 3:57 PM, Dirk Schenkewitz wrote:
>
>> 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)
>
>
> No you get the correct md5sum immediately by sniffing the network.
> Since the same md5sum would always be used for that user it is no
> better than sending the password as plaintext.
>
>> - but: the user's password does not need to be stored
>> in a well-known place in the repository any more.
>
>
> I think that's better because that one known place can be protected
> from access using the normal OS security and access control mechanisms.
>
> But you are correct, there are fairly easy things that can be done to
> fix it. E.g. store the hash of the plaintext password, issue a
> challenge from the server with a secure random number, the client
> responds with the result of hashing the password hash with the
> random number. The server checks that hashing the stored hash with
> the random number yields the same value. The data over the wire is
> random so sniffing doesn't help that much.
>
> I suspect that the current system does something similar but just
> starts with the plainttext password instead of a hash. (I'm not
> familiar with this stuff, i.e. cram-md5.)
>
> It can be done, but I wouldn't feel much more secure. If you can't
> protect the files on your filesystem from prying eyes you've got
> bigger issues in my opinion.
>
Hi Scott,
The problem here is not encrypting packets (just let ssh do this for
you) or protecting "files on your filesystem"...
the point is that to add a password to a repository someone should look
at the password file and he will see clear passwords for every users.
So even with the most thrusted repo admin you will not feel comfortable
to use your girlfriend sizes as a password...
At least this was my point (the clear text, not the sizes...) when I
asked for settings to control this.
In the end everyone can use an hash on "his" password and use this hash
as the svn password both on the server and with his client.
Moreover almost every svn client can store your password so you just
need to do this once, but definitely this wasn't an issue with cvs and
subversion should be better than cvs on everything ;)
Maurizio de Pascale
mdepascale@dii.unisi.it
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 16 00:01:16 2005