On Wed, Mar 19, 2008 at 10:45 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Hadmut Danisch <hadmut_at_danisch.de> writes:
> > Just read that:
> >
> > " Trust your OS to protect data on disk."
> >
> > That's nonsense. What do they believe why passwords stored by the
> > operating system are usually hashed and salted?
> >
> > What makes them believe that exactly that OS will be in place all time?
> >
> > That sort of approach is really silly. If you can't do it in a secure
> > way, than don't do it at all (at least not without explicit user
> > consent).
> >
> > The really bad thing about this is that it not just compromises
> > subversion, but can compromise the security of the whole LAN.
> >
> > Absolutely bad design.
>
> There are three choices:
>
> 1) plaintext passwords stored on server and client, so that crypttext
> travels over the wire.
>
> 2) plaintext travels over the wire (crypttext stored on server,
> client always has to prompt -- if client doesn't prompt, then
> "crypttext" just becomes a virtual plaintext)
>
> 3) some form of public key encryption
>
> If you are using (3), then this discussion doesn't concern you; you can
> set "store-passwords" to "no" in your config file and sleep easy. Try
> the 'svn+ssh://' access method, for example.
>
> If you're not using (3), then there are obvious tradeoffs between (1)
> and (2); use whichever way is best for you.
>
> And finally: "Don't complain; patches welcome" :-).
>
> You are complaining about bad design, but not offering any solution. If
> we *don't* store the passwords, then people will get prompted all the
> time -- we already know people don't like that; in fact, it's a
> showstopper for many users. You can see what the tradeoffs are here
> (the same as they have been forever). If you have a constructive
> suggestion to make, make it.
Currently svn provides both choices - it will store the password for you or
you can choose to not store as well. But we could look at his argument as to
keep the same two choices, but just make the default to not store the
password. The config parameter can be changed by users if they wish to (to
make store-passwords to 'yes' to make it store the password).
That is, if svn stores password, it is because the user knowingly set the
appropriate configuration value after considering the security implications
etc.
We can argue that it is the case even now, because the documentation/FAQ etc
make it very clear what svn is doing and the user has the option to turn it
off. But again, people (that includes me) RTFM only when they encounter a
problem. Until then we all think we can get it done after reading the Readme
file!
Thanks,
-Hari
PS: I have no problem with the design and I have had no issues with the
password storing issue. When I set up the repository the first time, I had
done enough experiments to know that the password was stored and I had
appropriately indicated it to our engineers. Here, I am only trying to make
sense of what is best.
Received on 2008-03-20 07:08:09 CET