RE: svnserve password store in clear text

> -----Original Message-----
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Wednesday, June 02, 2004 11:38 PM
>
> As with most people who make this request, you're starting from the
> (reasonable) misconception that the client transmits the
> password to the server.

Misconception is for those who don't do their homework. I on the other hand
was looking into the problem for quite a few days before posting (including
reading the source code that performs the authentication in the
libsvn_ra_svn library). :)

> That's not how it works; the server sends a
> challenge, and the
> client sends a response proving that it knows the password. For this
> "shared secret authentication" mechanism to work, the server
> has to know the password itself, not a one-way hash of it.

Let me clarify by saying that I don't have an issue of how the
authentication works in subversion. I just don't like administering the
password file with password in clear text. The users don't like the fact
that I can find out their password because it is store in clear text and I
don't like to know their password (especially if they want to use the same
password for other systems). I also don't like the fact that there is a
possibility that if I am editing the password file and someone is looking
over my shoulder to 'steal' the users password and/or potentially mine.

> There is a potential out here; the server and client only
> have to share
> a secret, not necessarily the password itself. I will, at some point,
> look into a way to make it so that the secret is a hash of
> the password
> together with the authentication domain. I didn't do this initially
> because (1) it's not how CRAM-MD5 is specified, and (2) it complicates
> repository administration and requires us to provide an extra
> command-line tool to perform the password encryption.

I have a proposal. Here goes:

In the libsvn_ra_svn library the compute_digest (in cram.c) function the
first few lines is a if statement that will copy the password to an unsigned
char secret[64] if the password is <= size of secret[64] and apr_md5 the
password into secret[64] if it is > size of secret[64]. I believe the code
speaks better:

  /* Munge the password into a 64-byte secret. */
  memset(secret, 0, sizeof(secret));
  if (len <= sizeof(secret))
    memcpy(secret, password, len);
  else
    apr_md5(secret, password, len);

Maybe we can store the password in apr_md5 format and change this segment to
perform a apr_md5 if called by a client and just copy over if called by the
server. Either that or have a compute_digest_server function where it will
perform the same thing except apr_md5 the password. I am thinking that if
the change is only on the server side, the client will not need to change.

I have to admit that my limited knowledge in cryptography and security is
not helping me to come up with a better authentication method. So, I throw
it to the floor to get opinion about the proposal.

On the other hand, I have not been able to get apr_md5 to work as what I
have expected. Either I am expecting the wrong thing, or there is something
else that is causing my test program not to work. No matter what I try, the
string obtained by calling the apr_md5 is not in the ASCII space. Most of
the character returned by this function is in the extended ASCII space. Am I
missing something? The ARP docs is really of no help.

I have also tried using the apr_md5_encode function in the same test program
but it worked as expected and the string return is similar to the password
hash in the system shadow file (i.e. "$apr1$somesalt$passwordhash"). Am I
missing something?

Regards,

Han.

----
Ng, Wey-Han
Atos Origin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org