On Fri, Jun 04, 2004 at 12:15:42AM +0200, Branko ??ibej wrote:
> Mark Benedetto King wrote:
>
> >On Thu, Jun 03, 2004 at 12:02:32PM +0800, Ng, Wey Han wrote:
> >
> >
> >>I have a proposal. Here goes:
> >>
> >>In the libsvn_ra_svn library the compute_digest (in cram.c) function the
> >>
> >>
> >
> >Your suggestion boils down to "have svn treat the secret as if it were
> >really MD5(secret)".
> >
> >If the problem you're trying to solve is one of people not liking their
> >favorite plaintext passwords to exist in files on the svn server, why
> >not just have them generate hashes of their plaintext passwords and
> >send you those? You can put those in the password file (or write a
> >CGI program to do it).
> >
> >They enter that hash rather than their plaintext password the one time
> >that svn asks them for it, and voila, everything works.
> >
> >As an added benefit, they can use whatever hash function they want!
> >
> >
> That doesn't mean a thing, you know. Anyone who can read the "hashed"
> password can still spoof the user id -- since it's not actually hashed,
> it's just a weird-looking plain text password.
Exactly! And anyone reading a base64-obfuscated password can go
base64-deobfuscate it, too.
It's difficult for the client to prove it knows a secret that the
server cannot be trusted to know without a PKI of some sort. Maybe
the right thing to do is implement STARTTLS, and do plaintext-over-TLS
authentication (analogous to HTTPS+BasicAuth). The password file
could then hold two types of entries: unencrypted, which would work
for "CRAM-MD5" and "LOGIN" authentication mechanisms, and crypt()ed,
which would only work with "LOGIN" (and perhaps most clients would
refuse "LOGIN" except under TLS).
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 4 00:38:02 2004