The problem with most, if not all, of the suggestions in this thread (and
its previous incarnations) is that they are all rather "shoot from the hip"
approaches. They all lack a fundamental *threat analysis*. Such an analysis
should at least include answers to these questions:
* Which resource do we want protect?
* Against who do we want to protect this resource?
* Against what kind of action do we want to protect this resource?
Before any technical suggestion is made, people in the discussion should
at least agree on the answers to these questions (particularly, the who
and action). Otherwise, people will continue making suggestions and counter
suggestions, and the discussion will eventually die out (as it has before).
I suspect this is the reason the subversion developers have not picked up
on this (frequently) re-emerging "idea."
For those who don't know: The subversion book clearly states that the svn
protocol uses CRAM-MD5 challenge-response authentication method:
>
> In essence, the server sends a bit of data to the client. The client uses
> the MD5 hash algorithm to create a fingerprint of the data and password
> combined, then sends the fingerprint as a response. The server performs
> the same computation with the stored password to verify that the result
> is identical.
>
> ** At no point does the actual password travel over the network. **
>
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,
bugtrackers,
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).
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 16 23:26:42 2005