Gerco Ballintijn wrote:
> So, eavesdroppping will not get you the password. However, the
> repository administrator will know your password since he has added
> it to the password file. The application and system administrator
> also have access, either directly or indirectly.
> The problem is not that he can use this password to access the
> repository since he can use simpler ways. The problem comes if the
> user of the repository
> whishes to *reuse* this same password for other purposes, such as,
> wiki's, or his paypal/ebay account?
> Given the number of password to remember this kind of sharing is
> inevitable, so to answer my own questions:
> Q: What resource do we want protecting?
> A: My low-grade *reused* password
> Q: Against who do we want to protect this resource?
> A: Against the repository administrator, and the application- and
> system administrator of the repostory server.
> Q: Against what kind of action do we want to protect this resource?
> A: Illegal password use on *other* web services.
> Given this (very) short analysis, I would place the "plaintext
> password problem" in the minor inconveniences category. The problem
> can however easily
> be solved by storing a secure hash of the password on the server,
> letting the
> client compute this hash before authentication, and using the hash
> for the challenge-response (instead of the password itself).
Very good point, and a large part of why I feel the svn client should
allow the end-user to change their passwords on svnserve'd repositories.
(I posted more of my reasons earlier in this thread, and so far, at
least, no one has put forward any reasons this shouldn't happen...)
I'm administering the svn repo at my office, and for a variety of
reasons, we decided to go with svnserve. Most people keep their
passwords for the various systems in the office "in sync", since
otherwise they'd need to remember a rather prohibitive list of
passwords. However, since the client doesn't allow the user to change
their password, I have to know everyone's svnserve password, so they
(obviously) can't use their standard passwords. This is, of course,
annoying to everyone involved.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Nov 17 14:43:18 2005