Hi Bert,
Bert Huijben (TCG) wrote:
>
> The current design was chosen to make it possible to only transfer a
> not-decipherable hash over the network.
>
>
> To make it possible to transfer a not-decipherable hash of the password over
> the network a local copy of the password must be available, either typed by
> the user or from some storage backend.
>
> The only other option for password authorization is storing a hash locally
> and transferring that exact same hash. But that would make the hash (for the
> authentication) the password itself.
>
> Sending the password plain text to the server doesn't seem the right thing
> to do. (If I can't trust the local machine I certainly can't trust the
> network.)
>
>
Well, this paraphrases the discussion we had on the users list.
There are major security flaws in that sort of argumentation.
1.) Beeing able to use hash authentication does not necessarily
require to store the password in plaintext without user's consent.
If you really need to perform hash authentication, there are still
two options:
a) Let the user enter the password every time, which is required by
most security policies. Storing the password in plaintext is a
severe
violation of almost all security policies.
b) If you really need to do it that way, then require the user's
consent
to store a password, but never ever do it silently without user
confirmation.
Your argument does not tell why the user should not confirm
storage
of the password.
2.) It is wrong that security requires hash authentication and thus
local storage
of the plaintext password. This is outdated technology and has the
disadvantage
that the server needs to have the password in plaintext as well.
One method to deal with that is the usage of one-time-passwords.
The better choice is to use SSL-Encryption (i.e. HTTPS) for the
server side. This
allows the server to e.g. authenticate against an LDAP server or
any hashed
password file without the need to store passwords in plaintext on
the server side.
The security model chosen for subversion is based on the (wrong)
assumptions that the passwords
are used for the subversion repository only and that the attacker is
only a wiretapping attacker, without
access to the machine. Although I agree that this threat model applies
to common open source applications
with a central server and many independant developers on the world with
lower security requirements,
it does not hold for company networks where the subversion repository is
covered by a HTTPS webserver
authenticating against a company LDAP server.
>
> If the subversion binary is able to decipher a password from disk using
> reversible encryption; any other software package could do the same by just
> copying our code.
>
And this is the best reason why you shouldn't do it without user consent.
BTW, you could do it the way other software does it, i.e. encrypt with
a master password.
However, it is not a good idea to store the password silently without
user's consent.
> The only thing that could help subversion is the OS. (On Windows and Mac
> pc's the os encrypts the passwords for us; patches for other operating
> systems are welcome ;-)
>
No. The user could enter the password every time he accesses the
repository.
That's how it is done in a local network over here due to the security
policy.
Works well except for the fact that too many passwords can be found on the
hard disk.
>
> These answers should (in other words) be available in the mailing archive...
> probably quite a few times, as it is a quite commonly asked question
>
Yup, it's the same answers again and again. I heard exactly the same
arguments
on the user mailing list, and obviously everyone who raised that issue
before got
the same answers.
Security flaws don't get any better by repeating them a hundred times.
The way those
answers are repeated again and again has some taste of ignorance. It's
even in the FAQ
and the handbook.
It's a good idea to document security problems. It's an even better idea
to fix them.
The more you repeat your answer, the less you're able to listen and the
more difficult
it is to convince you that this should be changed.
>
>
> However there are other ways to authenticate -like certificates- which don't
> have this problem and are secure even if you don't trust the file store. But
> that would require another server setup.
>
> http:// / https:// : Subversion 1.3+ allows using client certificates and
> SSPI connections (Windows only) over http and https. This does not even
> require typing the password in subversion.
> (We use this method extensively at The Competence Group)
>
> (There should be a few new options in the newer neon versions used by 1.5
> but I haven't really looked at them)
>
Maybe, but only few company networks support common certificates.
Common passwords in ADS/LDAP are currently standard.
>
> svn:// : Subversion 1.5+ allows using all sasl authentication types to
> authenticate to svn:// servers. (NTLM, SSPI, Kerberos, etc) which all have
> their own forms of authentication without storing passwords locally. (It
> also has other options to store it)
> (I'm looking at using this option to speed up common operations)
>
> This should work for all common operating systems. Especially the Kerberos
> authorization should be a viable option in corporate environments using a
> single logon environment over several systems.
>
Well, this might be nice, but that's not the point. It is not a matter
of the authentication mechanism. You're trying to solve a different
problem.
The given problem is as easy as: Do not store a password in plaintext
except if
the user explicitely and in this very moment confirms to do so. Just require
the user to tell for every single password that this is what he wants to
have.
There's no need to discuss details of authenticition mechanisms, because
that does
not make any difference in how to treat secrets.
> Changing the autorization to one of the above methods lets the server
> administrator choose what to store.
>
Again: I did not ask for a different authenticition mechanism.
I've asked to not store the password on the disk.
> But in my personal opinion: if you don't trust the user/the os in keeping
> their settings safe, you (as sysadmin) have already lost.
>
And in my personal opinion: This is terribly wrong.
Operating systems fail, Operators do make mistakes, and hard disks get
stolen or replaced.
It is common and accepted practice to not store passwords in plaintext,
and this violates most known security policy.
Sorry, do not want to offend you, but having a personal opinion does not
fix a security problem.
> My windows account I use for development does not have any more rights than
> absolutely necessary (less rights than most of my colleagues). For my
> sysadmin tasks I have a bunch of other accounts of which I will never use
> the password in any client application.
>
What makes you assume that any account on the world
is similar to yours?
> Even if we would like to (which I don't expect as the current design was
> discussed thoroughly in the initial design stage of subversion), we could do
> this only for subversion 2.0.
>
> We would break every rule about keeping subversion compatible over 1.x by
> applying such a change.
>
It should not make subversion incompatible in any way if the user would
have to give a command line option to have subversion store the password
on the disk. It would not change procedures and
protocols in any way. It would behave as if you had turned password
storage off in the configuration except
for the fact that you cannot forget to turn it off.
How should it make subversion incompatible if you already support what I
am asking for?
It is just to remove that behaviour of silently storing the password.
Again, I do not ask to change any protocol or mechanism. Just turn this
configuration
option into a command line switch. Pretty simple.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-06 21:25:35 CEST