* Nico Kadel-Garcia <nkadel@comcast.net> [2006-07-15 09:54:48]:
> Oh, please. it's a serious problem to have user passwords in a plain-text
> format under any circumstances. People are putting Subversion on Windows
> boxes, public servers. The servers and their configurations need to be
> backed up: should the backups contain the user's plain-text passwords? And
> how will you guarantee that users do not pick the same passwords for
> however you set up svnserve.conf as they use for other logins, that you
> should not as an admin know?
>
> Even if you trust the OS, why should have to trust the administrator with
> your plain-text passwords?
Which is why we offer other transport and serving methods that do not
require exposing plaintext passwords, like svn+ssh and https. We also
state that when using plaintext passwords, the correct use procedure
is that the admin generates a random password for the user, which the
user then "remembers" through client-side credential caching.
And no, contrary to what you are saying, having plaintext passwords is
not necessarily a serious issue, provided the security policy takes it
into account in implementation of machine protection, backup storage,
etc. Relying solely on passwords being mangled is as poor a security
policy as any.
Also, I'll repeat that we are working on implementing full SASL
support, which will let you choose a mechanism that does not have
those perceived weaknesses. This has always been planned, but
implementing only CRAM-MD5 in a first stage was an easy way of getting
svnserve out the door with good security over the wire and reasonable
server-side security (if you have a complete security policy), and
getting it out before 2010.
Just to emphasize this: CRAM-MD5 will not be "fixed" by providing
pseudo-obfuscation of stored passwords. It is a standardized
authentication protocol that has plaintext storage on the server as
one of its characteristics. If you do not like that characteristic,
there is svn+ssh:// and https:// transports, which implement countless
other protocols through PAM and Apache HTTPd, which you can choose
from. In future releases, there will also be that kind of choice for
svn://. I'm not sure what more we can offer here: we have
alternatives at present, and resolution is forthcoming.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 15 16:17:45 2006