You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/12/11 19:46:50 UTC
Re: passwords in subversion
On Dec 11, 2004, at 1:17 PM, Rainer Pröbster wrote:
>
> I find it unnecessary problematic that in the not uncommon case that
> you don't
> want or can't use an apache server (your first usecase) and you don't
> or
> can't use ssh (your third usecase) you have to write your passwords
> plain
> into a text file (your second usecase) in subversion.
> Nowaday nearly every "normal" (linux) program which is critical for
> the system
> (like every server is) stores it's passwords in an encrypted file,
> mostly in a simple linux password file.
> I really _hate_ it to edit clear text password files, as everyone who
> just
> passes behind me, can read them!! It's just unprofessional!
> If one could use "normal" linux password files with the svnserve server
> program (which I prefer much over the apache-plugin btw.) there would
> also be
> big advantages like reusing existing files or admin-programs.
>
Hey Ben Reser -- do you believe me now? Rainer is repeating what I've
heard over and over: that despite making a file chmod 700, users still
complain about the fact that "everyone who passes" by the screen can
read them. This is why I continue to advocate even *trivial* ciphering
like rot13. I'm tired of hearing this complaint.
Rainer: the problem is cryptograhpically tricky. If the server stores
hashed passwords (like those in htpasswd, or in /etc/passwd), then
cleartext passwords must pass over the network. If the server stores
cleartext passwords, then hashes may pass over the network. So which
do you prefer? Remember that you can make your password file readable
only by 1 person. So the tradeoff here is that if you just happen to
'cat' the contents of the password file, somebody can look at your
screen... but in return, the password never travels over the network in
the clear.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by John Szakmeister <jo...@szakmeister.net>.
On Saturday 11 December 2004 14:46, Ben Collins-Sussman wrote:
> On Dec 11, 2004, at 1:17 PM, Rainer Pröbster wrote:
[snip]
> Hey Ben Reser -- do you believe me now? Rainer is repeating what I've
> heard over and over: that despite making a file chmod 700, users still
> complain about the fact that "everyone who passes" by the screen can
> read them. This is why I continue to advocate even *trivial* ciphering
> like rot13. I'm tired of hearing this complaint.
I think a trivial encoding would at least be a good starting point.
> Rainer: the problem is cryptograhpically tricky. If the server stores
> hashed passwords (like those in htpasswd, or in /etc/passwd), then
> cleartext passwords must pass over the network. If the server stores
> cleartext passwords, then hashes may pass over the network. So which
> do you prefer? Remember that you can make your password file readable
> only by 1 person. So the tradeoff here is that if you just happen to
> 'cat' the contents of the password file, somebody can look at your
> screen... but in return, the password never travels over the network in
> the clear.
This is a limitation of CRAM-MD5. Could we chose a different algorithm?
FWIW, Windows uses a HASK(HASH(password)+token) type algorithm (well, it
used to before Active Directory started using Kerberos). It stores
HASH(password) in the registry. That way if the network connection goes
down, it will still allow you access to the machine. In this case, your
password never goes cleartext over the machine, and the cached entries
are "encrypted". Although, in this case, having the password hash is the
same as having the password, at least it's more difficult for someone
walking by to remember what it is.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by "Martin A. Brooks" <ma...@hinterlands.org>.
Jim Correia wrote:
> I'm not going to do anything malicious with my users' passwords, and
> they know that. But people being what they are, tend to reuse
> passwords and I'd rather avoid even having to see their passwords if I
> could.
How about adding support for SASL? It's simple enough and means svn
users don't need to have local accounts on the svn server itself. SASL
supports several encryption and obfuscation schemes.
Start reading here: http://asg.web.cmu.edu/sasl/
Regards
Mart.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by "Martin A. Brooks" <ma...@hinterlands.org>.
Jim Correia wrote:
> I'm not going to do anything malicious with my users' passwords, and
> they know that. But people being what they are, tend to reuse
> passwords and I'd rather avoid even having to see their passwords if I
> could.
How about adding support for SASL? It's simple enough and means svn
users don't need to have local accounts on the svn server itself. SASL
supports several encryption and obfuscation schemes.
Start reading here: http://asg.web.cmu.edu/sasl/
Regards
Mart.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by Jim Correia <ji...@pobox.com>.
On Dec 11, 2004, at 2:46 PM, Ben Collins-Sussman wrote:
> Hey Ben Reser -- do you believe me now? Rainer is repeating what I've
> heard over and over: that despite making a file chmod 700, users
> still complain about the fact that "everyone who passes" by the screen
> can read them. This is why I continue to advocate even *trivial*
> ciphering like rot13. I'm tired of hearing this complaint.\
Perhaps an alternative or additional solution is to ship a script - say
svnpasswd - that can manage the password file like htpasswd does. The
admin could still open up and see all the passwords this way, but it
gives a way to manage user passwords without opening up the file and
having to see all the passwords.
I'm not going to do anything malicious with my users' passwords, and
they know that. But people being what they are, tend to reuse passwords
and I'd rather avoid even having to see their passwords if I could.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Michael Sweet <mi...@easysw.com>.
Daniel Patterson wrote:
> ...
> (Is this how HTTP Digest authentication works? I should go read the
> RFC...)
Yes, although with HTTP Digest both the client and server may add
a "nonce" value to the hash, and there is the option of adding the
entire message body to the hash as well (MD5-sess).
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Greg Martyn <gm...@verizon.net>.
On Sunday December 12, 2004 5:39 pm, Greg Hudson wrote:
> * On the client side (this is not specific to ra_svn), rather than
> writing our own svn-agent as has been proposed, we should keep our
> eyes open for libraries which do secret management. GNOME has one
> at this point; maybe it's good enough for us.
kde has kwalletmanager..
Re: passwords in subversion
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Agreed. But rather than implement a whole new (almost identical)
> authn system, why not just have svnserve store the user-db with a
> trivial scramble. It solves the same "over the shoulder" problem,
> with a lot less work.
We will then get lots of posts saying "Do you realize your server-side
password encryption is totally insecure?" (As happened with CVS, to a
degree.)
Of course, our answer will be "Yes, we know that." But if the point
is to avoid stimulating these posts, I'm not sure that moving from
plaintext to trivial-scrambling is going to be effective.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Agreed. But rather than implement a whole new (almost identical)
> authn system, why not just have svnserve store the user-db with a
> trivial scramble. It solves the same "over the shoulder" problem,
> with a lot less work.
We will then get lots of posts saying "Do you realize your server-side
password encryption is totally insecure?" (As happened with CVS, to a
degree.)
Of course, our answer will be "Yes, we know that." But if the point
is to avoid stimulating these posts, I'm not sure that moving from
plaintext to trivial-scrambling is going to be effective.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Greg Hudson <gh...@MIT.EDU>.
Secret management is a complex, open-ended problem on both the client
and the server side of any network application. I don't think
Subversion should entangle itself very far in this realm without the
help of (optional) supporting libraries.
svnserve's cram-md5 support is a deliberately oversimplified stopgap
solution to the authentication problem. I could have made the shared
secret a hash of the password rather than the password itself, but
that would have meant requiring a tool to maintain the server password
file. While I'm quite aware that staring at a list of plaintext
passwords is at best uncomfortable to the administrator, I really
didn't want Subversion to have more than a tiny amount of its own code
devoted to a security protocol implementation. If svnserve were to
store hashed secrets, we'd still have the complaints that users have
no in-band way to change their passwords, that svnserve doesn't
integrate with some existing password database, etc..
Here's what I suggest for security-conscious sites which want to use
svnserve password authentication for whatever reason: don't let users
select the passwords. Assign them randomly and provide users with a
way of fetching them. (This could be done via https or various
lower-tech solutions.) The users will likely be using svn's
password-caching and won't need to remember the password. If the
admin uses a screen which can be seen by passers-by, write a small
script to manipulate the password database so that passwords don't
show up on the screen.
Obviously, in an ideal world Subversion admins shouldn't have to write
scripts to do out-of-band password management. Here are long-term
solutions I would find reasonable:
* Integrate Cyrus SASL. I have a number of issues with this
library, but we should probably just ignore all of them and
integrate it anyway. Note, however, that Cyrus SASL stores
cleartext passwords for digest-md5 and cram-md5 auth; it just
stores them in a database.
* Allow plain-text password auth if the connection is using SSL.
This allows integration with a variety of back-end password
databases, and Cyrus SASL will take care of the details (PAM,
Kerberos, maaaybe NTLM on Windows but I'm not sure). Even if the
admin uses local Subversion password database, it can contain
hashed passwords if PLAIN authentication is used.
* On the client side (this is not specific to ra_svn), rather than
writing our own svn-agent as has been proposed, we should keep our
eyes open for libraries which do secret management. GNOME has one
at this point; maybe it's good enough for us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by pat <pa...@xvalheru.org>.
Thanks to all !!!
Pat
Ben Collins-Sussman wrote:
>
> On Dec 12, 2004, at 1:04 AM, Daniel Patterson wrote:
>
>>
>> Server stores HASH(pw)
>>
>> Client generates random token, and calculates this:
>>
>> authstring = HASH(HASH(pw)+token)
>
>
> IIRC, svnserve is doing CRAM-MD5 right now, which is *almost* the same
> thing:
>
> authstring = HASH(pw + token).
>
>>
>> Client sends "authstring,token" to server. Server can recalculate
>> authstring to verify that the client knew "pw" (or at least,
>> HASH(pw)). Neither "pw", nor "HASH(pw)" are ever sent over the
>> wire.
>
>
> And in CRAM-MD5, the server stores cleartext "pw", so it knows that the
> client knew "pw". Just like digest auth, the password never travels
> over the network in the clear.
>
>>
>> If someone can get copies of the hash, then you're still screwed
>> (the hash is basically the password), but hopefully, hashes are harder
>> for people to remember by looking over your shoulder.
>>
>
> Agreed. But rather than implement a whole new (almost identical) authn
> system, why not just have svnserve store the user-db with a trivial
> scramble. It solves the same "over the shoulder" problem, with a lot
> less work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 12, 2004, at 1:04 AM, Daniel Patterson wrote:
>
> Server stores HASH(pw)
>
> Client generates random token, and calculates this:
>
> authstring = HASH(HASH(pw)+token)
IIRC, svnserve is doing CRAM-MD5 right now, which is *almost* the same
thing:
authstring = HASH(pw + token).
>
> Client sends "authstring,token" to server. Server can recalculate
> authstring to verify that the client knew "pw" (or at least,
> HASH(pw)). Neither "pw", nor "HASH(pw)" are ever sent over the
> wire.
And in CRAM-MD5, the server stores cleartext "pw", so it knows that the
client knew "pw". Just like digest auth, the password never travels
over the network in the clear.
>
> If someone can get copies of the hash, then you're still screwed
> (the hash is basically the password), but hopefully, hashes are
> harder
> for people to remember by looking over your shoulder.
>
Agreed. But rather than implement a whole new (almost identical) authn
system, why not just have svnserve store the user-db with a trivial
scramble. It solves the same "over the shoulder" problem, with a lot
less work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by Paul Querna <ch...@force-elite.com>.
Daniel Patterson wrote:
> (Is this how HTTP Digest authentication works? I should go read the
> RFC...)
Yes.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Michael Sweet <mi...@easysw.com>.
Daniel Patterson wrote:
> ...
> (Is this how HTTP Digest authentication works? I should go read the
> RFC...)
Yes, although with HTTP Digest both the client and server may add
a "nonce" value to the hash, and there is the option of adding the
entire message body to the hash as well (MD5-sess).
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 12, 2004, at 1:04 AM, Daniel Patterson wrote:
>
> Server stores HASH(pw)
>
> Client generates random token, and calculates this:
>
> authstring = HASH(HASH(pw)+token)
IIRC, svnserve is doing CRAM-MD5 right now, which is *almost* the same
thing:
authstring = HASH(pw + token).
>
> Client sends "authstring,token" to server. Server can recalculate
> authstring to verify that the client knew "pw" (or at least,
> HASH(pw)). Neither "pw", nor "HASH(pw)" are ever sent over the
> wire.
And in CRAM-MD5, the server stores cleartext "pw", so it knows that the
client knew "pw". Just like digest auth, the password never travels
over the network in the clear.
>
> If someone can get copies of the hash, then you're still screwed
> (the hash is basically the password), but hopefully, hashes are
> harder
> for people to remember by looking over your shoulder.
>
Agreed. But rather than implement a whole new (almost identical) authn
system, why not just have svnserve store the user-db with a trivial
scramble. It solves the same "over the shoulder" problem, with a lot
less work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Paul Querna <ch...@force-elite.com>.
Daniel Patterson wrote:
> (Is this how HTTP Digest authentication works? I should go read the
> RFC...)
Yes.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by Daniel Patterson <da...@danpat.net>.
Ben Collins-Sussman wrote:
>
> Rainer: the problem is cryptograhpically tricky. If the server stores
> hashed passwords (like those in htpasswd, or in /etc/passwd), then
> cleartext passwords must pass over the network. If the server stores
> cleartext passwords, then hashes may pass over the network.
Actually, you can have the best of both worlds.
Server stores HASH(pw)
Client generates random token, and calculates this:
authstring = HASH(HASH(pw)+token)
Client sends "authstring,token" to server. Server can recalculate
authstring to verify that the client knew "pw" (or at least,
HASH(pw)). Neither "pw", nor "HASH(pw)" are ever sent over the
wire.
If someone can get copies of the hash, then you're still screwed
(the hash is basically the password), but hopefully, hashes are harder
for people to remember by looking over your shoulder.
(Is this how HTTP Digest authentication works? I should go read the
RFC...)
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Ben Reser <be...@reser.org>.
On Wed, Mar 02, 2005 at 09:25:09AM +0100, Branko ??ibej wrote:
> Ben Reser wrote:
>
> >However, the client side problem is much trickier. In order for caching
> >to work with all authentication protocols we must cache the plaintext
> >password.
> >
> >
> You don't actually have to store the plaintext on either the client or
> the server if you're doing CRAM-MD5, which svnserve does; you can store
> an intermediate result instead. That keeps the passwords secure on the
> server side (but not, of course, on the client side, where the
> intermediate result is just another way to say "plain text password").
First to respond to Branko specifically, note that I said all
authenticatin protocols. Yes there are ways with specific protocols
e.g. CRAM-MD5 that lets us avoid writing the actual plaintext. But as
you point out it's really just as good as the password anyway.
Here's my thoughts on what I'm planning to do:
~~~Client side~~~
Ultimately, there aren't really very many solutions to the client side
caching problem. But I also don't think what we're currently providing
is what users really want.
I don't believe that most users want to enter a password once and then
never have to enter it again for that repository. I think most
users simply want to avoid typing the same password in many times in the
same session. This is especially problematic considering that our
client only stays running for brief periods of time to carry out a
specific task in most cases (though there are exceptions like TSVN and
other clients).
Solutions for the client side I think are as follows.
Implement a svn-pwagent program that will handle password caching for
authentication protocols that transmit hashed information across the
network and for certificates. The agent would not actually reveal the
password the any client using it but would perform the calculations
needing the password for the client. i.e. calculating the hash or
retrieving the session key for things like SSL.
Anyone with access to the svn-pwagent would of course be able to request
that we do calculations for them for other protocols that happened to
use the same authentication protocols that we used. But only for as
long as the program was running. The password would not be forever
revealed to them.
This of course would not help anyone using plain text authentication
methods. However, there is no safe way of caching this information.
Incidentally, I'm not sure how well this can be implmented before 2.0.
Currently our authentication provider architecture doesn't know anything
about the specific authentication method being requested. I believe
we'll need to redesign the authentication provider system to support
this in a clean way. However, we might be able to write a separate
provider that handles "simple" authentication. Frankly, I just haven't
investigated how well the RA layers can be adapted to handle this. I'm
suspecting that it's undesireably ugly to do this without new APIs.
~~~Server side~~~
Storing the MD5 contexts (the term used by md5) would indeed alleviate
the majority of the server side concerns, but I don't think it resolves
the real issue. The concern most server admins make is that they're
concerned with people glancing at the passwords while they're working on
the file or with themselves actually seeing the passwords. The concern
with other people seeing is obvious. But seeing other users passwords
isn't a problem for the admin because he already has full access right?
This is true, but the retort always is that users recycle passwords and
that this recycling of passwords gives them access to something they
shouldn't.
Storing the contexts stops the admin from directly reentering a password
that they happened to see into any random protocol. However, if you
store the contexts and the other service that this password was recycled
on happens to also use CRAM-MD5 to protect its wire communcations, they
now can generate the final response to authenticate for that service.
The ultimate, gotcha on this issue is that the more services that use
CRAM-MD5 to secure passwords, the less valueable storing the contexts as
a method of protecting from such attacks really is.
Ultimately, you have a choice, you can do authentication in one of two
ways:
a) Server stores a one way hashed copy of the password. Client sends
the plaintext password. Server recalculates the password into a hash
and compares it to the hash it has stored. This protects against admins
using the password database to gain access to other services which use
the same password but may or may not protect the password while crossing
the network (see later). However, it still leaves the plaintext
password vulnerable to being in the servers memory. Though well coded
apps will place the password in non-pageable memory and clear and free
that memory as soon as they are done calculating the hash.
b) Server stores a shared secret, this might be the actual password or
some intermediate result of the password. Server sends a challenge that
includes a random component. Client responds with the result of a keyed
one way hash using the shared secret as the key and the challenge as the
text. Server calculates the hash with its own copy of the shared secret
and compares what the client sent to what it calculated.
In the case of an open source app (though being closed source doesn't
necessarily ensure more security here) it would be trivial to make it
accept the intermediares as the password. In fact that's what Branko's
point is about the intermediares being as good as passwords on the
client is about. Since if we store intermediares as the cache for the
client then you can just manually generate a cache if you know the
intermediaries. But even if we don't use this to cache the passwords,
then our client could be trivially modified to accept the
intermediaries. In fact you could probably just write an authentication
provider for it and add it to the list.
Would we be making people feel better if we did this? Probably. Would
we be buying any security? Some, but only for services that don't use
CRAM-MD5. IMHO this is a bad solution as it is realistically impossible
to evaluate this for the problem people are complaining about. You
can't possibly know ever service the user has recycled their password
on. And the evaluation would change over time. Maybe right now you're
using POP3 with plaintext passwords. But what if you switch to IMAP
using CRAM-MD5. Suddenly a hole is opened that wasn't there before.
What's the better solution?
The ideal solution is to ues publice key cryptography. Server and
client has a public/private keypair. Each only knows the others public
key and their own public and private key. In this way they know that
they are communicating only with each other. However, many people are
not willing to use certificates becuase they find them inconvient to
generate and use.
So the stop gap measure is to use server side certificates, to verify to
the client that it is talking to the right server. And then to send the
password in plaintext over the encrypted session based upon a key
exchange via this server public/private keypair.
So my solution for svnserve is as follows:
Implement a PLAIN authentication method. The PLAIN authentication
method will be configurable to be used only when the session is
encrypted (defaults to this configuration). It will work with hashed or
unhashed password files (for backwards compatability) again defaulting
to the more secure position of only using hashed password files.
Now of course this exposes users to the possiblity of revealing their
plaintext password to some bad server if the real servers certificate is
revelead to some unsavory character or the user simply ignores warnings
about the certificate changing. But it solves the problem that we're
trying to deal with here.
~~~End Result~~~
So let's consider the end result. Server admins can have password
databases that do not allow them to use the users authentication
information. Clients can have the ease of only having to type their
password ocassionally, without having to worry about someone stealing
their authentication information from on disk caches.
But what about when you want both of these things? There are only 2
options here.
a) svn+ssh using client keys and ssh-agent. We already fully support
this. It just works. However, some people are uncomfortable with the
shell access. It's not as easy to setup as some might like, especially
in light of file system permission issues with the repository.
b) http or svnserve with ssl using client certificates for
authentication. We also already support this for http and work is
currently going on to add ssl to svnserve. However, we currently don't
support a reasonably safe way of caching the certificate password at
current.
People with these concerns can be pointed towards these solutions. This
is exactly the course that ssh took. It makes a lot of sense and I
think the vast majority of security concious installations are using
client keys as opposed to passwords for ssh.
Ultimately, not everyone can have their cake and eat it too. But we can
provide some limited but reasonably secure solutions for people with
these concerns. We will have to educate users about the various trade
offs of these solutions and let them choose for themselves which one is
best. Switching to storing something that is just as good as a password
removes our ability to educate these users and let them have a more
secure system and ultimately compromises our abilitiy to claim that this
project claims about security.
Implementing obfuscation routines that makes users feel safer but
doesn't stop the attacker will only earn us a bad reputation when
someone takes advantage of that. We need to remember that users trust
us to be looking out for their security here. If they open up a
password file or cache and see "garbage" they're going to feel safe.
They won't evaluate the full security implications of what we're
actually doing. But if they see a plaintext password they know the
security implications without a doubt.
In summary, I think the project policy should be:
"Secure after a thorough review or obviously insecure."
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>However, the client side problem is much trickier. In order for caching
>to work with all authentication protocols we must cache the plaintext
>password.
>
>
You don't actually have to store the plaintext on either the client or
the server if you're doing CRAM-MD5, which svnserve does; you can store
an intermediate result instead. That keeps the passwords secure on the
server side (but not, of course, on the client side, where the
intermediate result is just another way to say "plain text password").
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Ben Reser <be...@reser.org>.
On Sat, Dec 11, 2004 at 01:46:50PM -0600, Ben Collins-Sussman wrote:
> On Dec 11, 2004, at 1:17 PM, Rainer Pröbster wrote:
> >
> >I find it unnecessary problematic that in the not uncommon case that
> >you don't
> >want or can't use an apache server (your first usecase) and you don't
> >or
> >can't use ssh (your third usecase) you have to write your passwords
> >plain
> >into a text file (your second usecase) in subversion.
> >Nowaday nearly every "normal" (linux) program which is critical for
> >the system
> >(like every server is) stores it's passwords in an encrypted file,
> >mostly in a simple linux password file.
> >I really _hate_ it to edit clear text password files, as everyone who
> >just
> >passes behind me, can read them!! It's just unprofessional!
> >If one could use "normal" linux password files with the svnserve server
> >program (which I prefer much over the apache-plugin btw.) there would
> >also be
> >big advantages like reusing existing files or admin-programs.
> >
>
> Hey Ben Reser -- do you believe me now? Rainer is repeating what I've
> heard over and over: that despite making a file chmod 700, users still
> complain about the fact that "everyone who passes" by the screen can
> read them. This is why I continue to advocate even *trivial* ciphering
> like rot13. I'm tired of hearing this complaint.
Okay this is once again talking about the server side. I think you've
confused the server side issue with the client side issue over and over.
I understand the admins complaining about this on the server side. But
the reason the passwords are stored in clear text is because of the
authentication design that Greg Hudson chose for svnserve. This only
applies to svnserve and only if you're not using ssh. The solution is
to either implement our own new authentication protocol that allows
plaintext passwords (especially since SSL is now in the pipe for
svnserve) or implement something like digest authentication that apache
uses.
As Karl pointed out later in the thread, implementing rot13 isn't going
to get rid of the emails. It isn't going to make things more secure.
If you think someone walking past your monitor is going to memorize a
password why can't they memorize the rot13 version of it and walk back
to their workstation and do: echo foo | rot
Adding a trivial cipher does not change the problem, it just hides it.
Greg suggests some excellent solutions to the problem in the short and
long term in his posts.
However, the client side problem is much trickier. In order for caching
to work with all authentication protocols we must cache the plaintext
password.
To this end I agree, I'm tired of hearing this complaints. So I'm
taking it upon myself to fix these issues. This means I'll be working
on svnserve to make it support additional authentication methods and
implementing svn-agent for the client side.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: passwords in subversion
Posted by Jim Correia <ji...@pobox.com>.
On Dec 11, 2004, at 2:46 PM, Ben Collins-Sussman wrote:
> Hey Ben Reser -- do you believe me now? Rainer is repeating what I've
> heard over and over: that despite making a file chmod 700, users
> still complain about the fact that "everyone who passes" by the screen
> can read them. This is why I continue to advocate even *trivial*
> ciphering like rot13. I'm tired of hearing this complaint.\
Perhaps an alternative or additional solution is to ship a script - say
svnpasswd - that can manage the password file like htpasswd does. The
admin could still open up and see all the passwords this way, but it
gives a way to manage user passwords without opening up the file and
having to see all the passwords.
I'm not going to do anything malicious with my users' passwords, and
they know that. But people being what they are, tend to reuse passwords
and I'd rather avoid even having to see their passwords if I could.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: passwords in subversion
Posted by Daniel Patterson <da...@danpat.net>.
Ben Collins-Sussman wrote:
>
> Rainer: the problem is cryptograhpically tricky. If the server stores
> hashed passwords (like those in htpasswd, or in /etc/passwd), then
> cleartext passwords must pass over the network. If the server stores
> cleartext passwords, then hashes may pass over the network.
Actually, you can have the best of both worlds.
Server stores HASH(pw)
Client generates random token, and calculates this:
authstring = HASH(HASH(pw)+token)
Client sends "authstring,token" to server. Server can recalculate
authstring to verify that the client knew "pw" (or at least,
HASH(pw)). Neither "pw", nor "HASH(pw)" are ever sent over the
wire.
If someone can get copies of the hash, then you're still screwed
(the hash is basically the password), but hopefully, hashes are harder
for people to remember by looking over your shoulder.
(Is this how HTTP Digest authentication works? I should go read the
RFC...)
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org