OK,
on the end of this mail you'll find my proposal to improve security.
Just to comment the arguments:
Karl Fogel wrote:
> 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
>
That's not applicable because you are confusing the security mechanisms.
While that hold's true if you focus on the authentication mechanism for
one party
only without any other protection mechanism, we have a different
situation here:
svn over HTTPS with plain password authentication, so the case of 2)
protected
in a 3) layer. So security on the wire is not the problem here (of
course, if you don't use HTTP instead of HTTPS).
A typical method of protection is to use a HTTPS server to keep the SVN
repository with webdav and to
do password authentication within that SSL connection.
The mistake in your argument is that in general (although not
necesseraly) it is the server who uses public key to authenticate
against the client, while the client uses a password to authenticate
against the server.
Always keep in mind that these are different "directions".
> 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.
>
Definitely not. svn+ssh requires to have an account on the operating
system of the server, with ability to login, while the HTTPS method just
needs the webserver to authenticate people without any need to have the
operating system know them. Furthermore, svn+ssh is too complicated and
simply a different thing.
svn+ssh is a way if the client has ssh access anyway. It is definitely
not a substitute for HTTPS.
E.g. I could give clients and business partners a password and HTTPS
access, but I would give them a ssh access to my server. And it some
cases this would be against required security standards.
Never do security the way "if there's a workaround, it ain't broken".
> If you're not using (3), then there are obvious tradeoffs between (1)
> and (2); use whichever way is best for you.
>
Again, this is wrong. Your argument is about the choice of the
authentication protocol and storage
of credentials on the server side.
I am talking about the client side who needs to keep the secret parts of
the credentials in any of the 3 methods you describe. Please be precise
about security.
> And finally: "Don't complain; patches welcome" :-).
>
Well, it would be easier and faster if those modified the source who are
familiar.
My proposal, all I ask for is this:
- Never ever store a password in clear on disk without explicit user
consent.
- Forget about the store* config values.
- Provide a special command line flag --store-password
- If that's not given, don't store the password. No default behaviour to
store passwords,
no accidential storage of passwords.
- print a warning message *before* transmission if a password is to be
used without wire
encryption (i.e. a HTTP connection)
If the user wants a password is to be stored:
- store the server name, the protocol (HTTPS/HTTP) and the
certificate as well (certificate is already stored, but link it to the
password)
- When a password was sent over a HTTPS connection, avoid to send it
over HTTP. distinguish protocols.
- A given password must (should) not be used automatically for any
different SVN respository
(could be a booby trap) .
So a good key to store the password in an local array might be something
like
https://user@server/repospath:certificate-hash
So whenever any part of this changes, a new password is to be asked for,
to avoid someone
else provoking to reveal a password.
> You are complaining about bad design, but not offering any solution.
See above. Pretty simple. Easy to implement.
> 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.
>
See above. If a user wants to store the password to eliminate the need to
enter it again and again, just require him to give the option
--store-password once and
have svn store the password.
I believe that's much more simple and comprehensible than it is now.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-20 22:24:52 CET