You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Robert <ro...@gmx.de> on 2004/12/27 00:48:17 UTC
Feature Request: clients shouldn't store auth-creds
Hello.
Would you please set store-auth-creds to no and uncomment that key
please in ~.subversion/config.
I have a DMZ with Web Server on which I work with svn for the web pages
and today decided to enforce digest auth in apache.conf. But for other
users (the clients) in a corporate network it is very confusing. Since
those people normally are no admins it doesn't make sense.
And it took me hours to change every working copy and the config on all
my accounts. On the other side enabling caching would be much faster.
In my opinion, security has to be enabled by default, if the password
dialog is annoying for some user, he should decide on his own.
Anyway there should be a server side mechanism to enforce that security
policy. Imagine someones account getting hacked and he has write access
(in a software developing company) the whole database could get screwed
up.
Thoughts?
Greetings,
Robert Welz
SVN 1.0.9,
several linux clients
and a Mac repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Marcus Rueckert <da...@web.de>.
On 2004-12-27 01:48:17 +0100, Robert wrote:
> And it took me hours to change every working copy and the config on all
> my accounts. On the other side enabling caching would be much faster.
did you know that you have could set the setting in
/etc/subversion/config and the value would be used for every user on the
box until they change it in their local config.
> In my opinion, security has to be enabled by default, if the password
> dialog is annoying for some user, he should decide on his own.
there was more than one discussion regarding cachine and password
storage. some proposed a svn-agent similar to the ssh-agent. a search on
the dev mailinglist archive should give you some links. [1]
darix
[1] http://svn.haxx.se/
--
irssi - the client of the smart and beautiful people
http://www.irssi.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Sun, Jan 09, 2005 at 11:08:00PM +0000, David Wilson wrote:
>
> I don't have any 'better' solution, and I doubt few, if any on this list
> do. What I do know, is that it takes many years and bad experiences
> before someone can come up with such a solution. That is the route I
> recommended we don't take.
>
An application layer proxy could provide an in-line credentials cache.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by David Wilson <dw...@botanicus.net>.
Branko Čibej wrote:
> This thread is not about implementing authentication or encryption
> mechanisms, it's about temporarily cacheing credentials so that a)
> they're not stored on disk, and b) users don't have to provide them
> (type passwords) all the time. There's a world of difference between
> the two.
My apologies, I meant the abstract goal of providing secure storage of
private data.
> For example, "sudo" will temporarily cache the fact that you've
> confirmed your identity in a particular login session, and whilst it
> doesn't use a separate process for that, I'd still classify it as
> having an "agent". Interestingly enough, what "sudo" does is quite
> similar to storing session tokens.
FWIW, I don't mind the idea of time-limited tokens so much. It seems odd
to me that nobody else has implemented something like that before. ;)
> Others have walked that path several times, and there's nothing wrong
> with learning from their experience.
The history of man is a powerful testament to the contrary!
Good night,
David.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Branko Čibej <br...@xbc.nu>.
David Wilson wrote:
>On Sun, Jan 09, 2005 at 09:15:50PM +0100, Branko ??ibej wrote:
>
>
>
>>>An agent program also introduces the following (especially on Windows):
>>>
>>>
>
>
>
>>*sigh* ... I'm so tired of "experts" who keep guessing about what
>>Windows can or can't do.
>>
>>
>Can you point to the part where I claimed to be an "expert", or said
>Windows can't lock memory? I merely hinted that it is less trivial to
>keep a hold of said memory on Windows, which as far as I know is true.
>
>
I could say, "less trivial than where?" but I'll just note that it's
easy to do and therefore we can ignore this issue.
>>>There are plenty of security books out there (eg. Writing Secure Code)
>>>that would tell you it is a very bad thing. In my opinion, the current
>>>practice of the Subversion folk is the ideal one - leave the
>>>complicated security (certificates, public keys, encryption, etc) to
>>>other people *who know what they are doing*.
>>>
>>>
>>The trouble is, of course, that they usually don't.
>>
>>
>
>Well, I'd rather leave the blame on their doorstep for claiming to be
>security products than bring it to Subversion's, it has already had
>enough security problems in its short life than enough ("zero" or "as
>low as humanly possible" being enough).
>
>
We can claim it's not our fault, but that isn't enough to change
people's perceptions.
>Like any project, it is understaffed enough for the problems at hand
>(ie. writing a version control system), without trying to take on the
>mammoth task of implementing a complex yet secure authentication /
>encryption / whatever system in C.
>
>
This thread is not about implementing authentication or encryption
mechanisms, it's about temporarily cacheing credentials so that a)
they're not stored on disk, and b) users don't have to provide them
(type passwords) all the time. There's a world of difference between the
two.
>>"Windy" indeed. :-)
>>
>>
>
>Your argument appeared to be "because others claim to know what they're
>doing and get it wrong, so should we". :)
>
>
Ah... that would be the case only if you were right, something I don't
agree with. :-)
>The intent of my first post was to shoot down a clearly bad design, and
>to praise the Subversion folk on not attempting anything like this.
>
>
But the whole point is that there /was/ no design to shoot down. I said
"agent", and you replied, "ssh-agent is bad, therefore any agent is
bad". I never claimed that an svn-agent should be a clone of ssh-agent.
For example, "sudo" will temporarily cache the fact that you've
confirmed your identity in a particular login session, and whilst it
doesn't use a separate process for that, I'd still classify it as having
an "agent". Interestingly enough, what "sudo" does is quite similar to
storing session tokens.
>I don't have any 'better' solution, and I doubt few, if any on this list
>do. What I do know, is that it takes many years and bad experiences
>before someone can come up with such a solution. That is the route I
>recommended we don't take.
>
>
Others have walked that path several times, and there's nothing wrong
with learning from their experience.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by David Wilson <dw...@botanicus.net>.
Travis P.: my apologies for not replying to your message personally,
I've been busy all weekend. The gist of what is said below would simply
be regurgitated if I were also to reply to your message. :)
On Sun, Jan 09, 2005 at 09:15:50PM +0100, Branko ??ibej wrote:
> >An agent program also introduces the following (especially on Windows):
> *sigh* ... I'm so tired of "experts" who keep guessing about what
> Windows can or can't do.
Can you point to the part where I claimed to be an "expert", or said
Windows can't lock memory? I merely hinted that it is less trivial to
keep a hold of said memory on Windows, which as far as I know is true.
> >There are plenty of security books out there (eg. Writing Secure Code)
> >that would tell you it is a very bad thing. In my opinion, the current
> >practice of the Subversion folk is the ideal one - leave the
> >complicated security (certificates, public keys, encryption, etc) to
> >other people *who know what they are doing*.
>
> The trouble is, of course, that they usually don't.
Well, I'd rather leave the blame on their doorstep for claiming to be
security products than bring it to Subversion's, it has already had
enough security problems in its short life than enough ("zero" or "as
low as humanly possible" being enough).
Like any project, it is understaffed enough for the problems at hand
(ie. writing a version control system), without trying to take on the
mammoth task of implementing a complex yet secure authentication /
encryption / whatever system in C.
> "Windy" indeed. :-)
Your argument appeared to be "because others claim to know what they're
doing and get it wrong, so should we". :)
The intent of my first post was to shoot down a clearly bad design, and
to praise the Subversion folk on not attempting anything like this.
I don't have any 'better' solution, and I doubt few, if any on this list
do. What I do know, is that it takes many years and bad experiences
before someone can come up with such a solution. That is the route I
recommended we don't take.
Cheers,
David.
--
(This signature left intentionally blank)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Michael W Thelen <mi...@pietdepsi.com>.
Ben Collins-Sussman wrote:
>> That's the kind of situation that it might be nice to avoid by
>> default, even if just by trivially scrambling the password.
>
> I've argued for a trivial scrambling in the past (like CVS does), but
> some folks are strongly against this, feeling that it will convey a
> false sense of security.
Oops, even after that whole anecdote, I forgot the point I was trying to
make. :-)
I would be in favor of a trivial scrambling of passwords, but I'm even
more in favor of not caching credentials by default. They're two
related but separate issues. The first thing that went wrong in my
story was forgetting to edit ~/.subversion/config, so passwords were
accidentally cached. The accidental nature of it bothers me more than
the plain text passwords. With credential caching off by default, at
least such accidents would be much less likely.
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
Re: Feature Request: clients shouldn't store auth-creds
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 4, 2005, at 8:50 AM, Michael W Thelen wrote:
>
> That's the kind of situation that it might be nice to avoid by
> default, even if just by trivially scrambling the password.
I've argued for a trivial scrambling in the past (like CVS does), but
some folks are strongly against this, feeling that it will convey a
false sense of security.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Michael W Thelen <mi...@pietdepsi.com>.
Greg Hudson wrote:
>>No, the password is scrambled which is of course not secure, but it does
>>provide glance-over-shoulder "security".
>
> Essentially worthless, since there's no need to look at the client
> password file.
I have accidentally glanced another person's password in the client
password file. This was on an account that is shared among several
users to do builds for our company's products. Before the no-auth-cache
default had been set in ~/.subversion/config, several users (including
myself) had performed Subversion operations that cached their passwords.
When I realized this, I decided to delete the file containing my
cached password.
Why I didn't just delete them all, I don't know. Why I didn't grep for
my username, I don't know. Being somewhat slow in the head, I catted
the first file in the directory, which happened to be someone else's
cached credentials. Whoops! When I realized what I was looking at, I
immediately got it off my screen, but the first few characters of the
password etched themselves into my head. Fortunately, I've forgotten
them now. I also told the person what happened, so hopefully the
password is changed anyway.
That's the kind of situation that it might be nice to avoid by default,
even if just by trivially scrambling the password. Was it my fault for
looking at the password file? Yes. But in a moment of stupidity I did
it anyway. I would guess I'm not the only one who's had this kind of
experience (but I hope I am).
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
Re: Feature Request: clients shouldn't store auth-creds
Posted by Tobias Ringström <to...@swedot.se>.
Greg Hudson wrote:
>(2) The safety of the password over the net is totally orthogonal to the
>safety of the password as stored on the client (or server). We already
>have a decent story there.
>
>
Well of course, and I never claimed otherwise.
>>Nobody uses CVS passwords because it is so insecure. Instead, most
>>people run CVS via ssh which does not store passwords. It's not a fair
>>comparison.
>>
>>
>But you can use svn over ssh too. It's almost exactly the same story,
>and it's a perfectly fair comparison.
>
>
It's not a question of what you can do, it's a question of what the
default use case is. I'm saying that because CVS has such a long history
of security holes, most admins stay away from pserver and use ssh
instead when using an insecure network, and that makes the comparison
that CVS stores passwords unfair. Subversion has a much better
reputation and because of the nice security mechanisms it gets from its
use of Apache httpd, ssh tunneling is not really needed in most cases,
and a comparison with ssh would be a lot more relevant.
It would be a much better situation if Subversion did not cache
passwords by default, and that you could either enable caching by
editing the config file, or make it cache the passwords it learns from a
single session by running something like "svn co --store-passwords".
It's secure by default, and it's also easy to understand and to
document. It's often the admin that cares if the users store their
passwords or not, and right now the admin has to instruct all users to
edit their config files (which is not oly platform dependent but also
difficult and error prone for non programmers). It's a much better
situation if the admin can just tell the users not to store their passwords.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-01-03 at 18:54, Tobias Ringström wrote:
> No, you run "cvs login" which has to store the password for obvious
> reasons. But it's an irrelevant comparison, because CVS passwords are
> not used over the Internet which is where security matters most. See below.
(1) The Subversion project used CVS passwords over the Internet, when we
used CVS. Lots of other projects do too.
(2) The safety of the password over the net is totally orthogonal to the
safety of the password as stored on the client (or server). We already
have a decent story there.
> No, the password is scrambled which is of course not secure, but it does
> provide glance-over-shoulder "security".
Essentially worthless, since there's no need to look at the client
password file.
> Nobody uses CVS passwords because it is so insecure. Instead, most
> people run CVS via ssh which does not store passwords. It's not a fair
> comparison.
But you can use svn over ssh too. It's almost exactly the same story,
and it's a perfectly fair comparison.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
>> 2) permits the following config settings:
>> cache_passwords = no
>> cache_passwords = yes
>> cache_passwords = ask
>
>
> I don't understand the usefulness of the last option.
Think of it as "mostly no but sometimes yes." It may be that I don't mind
caching the password to my own personal repositories, but I might not want to
cache the password for some external repository (lest someone hack my machine
and then add a trojan to some project I happen to have write access to).
> This would be a useful thing to have [svn-agent], although IIRC some people object
> to this on the grounds of it being too complex.
And the obvious drawback that it isn't written yet, so we cannot use it for
1.2.0... ;)
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>>>> The svnserve+ssh combo already has its own "private" solution
>>>> (with ssh-agent).
>>>>
>>>> The point of this idea is to avoid having the client send a
>>>> plaint text password in each request. I don't see any way of
>>>> dealing with this in Apache other than with a modified auth module.
>>>
>>> mod_auth_digest? https://?
>>
>> No. Both https and mod_auth_digest are ways to send a plain text
>> password securely. And this plain text password must be sent *every
>> time*. I'm talking about some server component (e.g. an apache auth
>> module) which would hand over temporary session tokens/credentials.
>> An administrator would be able to configure the expiry time of these
>> tokens (2 hours? 1 day? a week?).
>
>
> Ah. Do you realise that passing a session token back and forth in the
> clear is just as insecure as passing a cleartext password?
Of course, but the session token would expire in a short time, and it
can be made it so it's valid only when used from a certain IP address.
So if it gets stolen the damage is less than if a real password were stolen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Branko Čibej <br...@xbc.nu>.
Nicolás Lichtmaier wrote:
>
>>> The svnserve+ssh combo already has its own "private" solution
>>> (with ssh-agent).
>>>
>>> The point of this idea is to avoid having the client send a
>>> plaint text password in each request. I don't see any way of dealing
>>> with this in Apache other than with a modified auth module.
>>
>>
>>
>> mod_auth_digest? https://?
>
>
>
> No. Both https and mod_auth_digest are ways to send a plain text
> password securely. And this plain text password must be sent *every
> time*. I'm talking about some server component (e.g. an apache auth
> module) which would hand over temporary session tokens/credentials. An
> administrator would be able to configure the expiry time of these
> tokens (2 hours? 1 day? a week?).
Ah. Do you realise that passing a session token back and forth in the
clear is just as insecure as passing a cleartext password?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Robert <ro...@gmx.de>.
Am 14.01.2005 um 19:02 schrieb Greg Hudson:
> On Fri, 2005-01-14 at 11:06, Robert wrote:
>> Make the svn system supporting native kerberos (not PAM becourse of
>> the
>> plain text password floating through the network).
>
> We already do!
Oh, well, I didn't know that.
At the end of next week I set up my very first Heimdal Server, some
clients and the login of my computers. Then I will hopefully find the
time to test svn with. Is there svn specific documentation available?
If someone is interested I could write a little how-to, well, if I can
handle installation.
Again, thanx a lot!
But Kerberos surely is no easy solution for security so this should't
wipe the problematic of having an easy method for
authentification/autorization.
Last sentence is just my 2 ct.
Greetings,
Robert Welz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-01-14 at 11:06, Robert wrote:
> Make the svn system supporting native kerberos (not PAM becourse of the
> plain text password floating through the network).
We already do!
Over HTTP, neon supports negotiate auth. I've made it work with
mod_auth_kerb (I'm not sure what the functional differences are between
that and modgssapache), although I had to fix a one-line bug in Neon.
See http://mailman.webdav.org/pipermail/neon/2004-November/001768.html
for details.
You can also use Kerberos authentication via svn+ssh, although the ssh
Kerberos situation is still a little murky, I think. But it can
definitely be made to work.
Some day we hope to integrate a SASL library into svnserve, which would
allow Kerberos authentication via svn:// as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Robert <ro...@gmx.de>.
Hello.
I have followed the discussion a bit and I like to suggest the
following.
Make the svn system supporting native kerberos (not PAM becourse of the
plain text password floating through the network).
I would suggest NTLM and SPNEGO auth mechanism
(http://modgssapache.sorceforge.net. I know this works actually only
with MS InternetExplorer but since Apple for example supports
subversion in the developer tools they may then be tempted to support
NTLM in Safari, too. Probably Mozilla and the Mozilla based Linux
Browsers will follow.
Before I start recherching I would like to know what you think about
this idea in general.
Lit.: O'Reilly: Kerberos The Definite Guide, page 145ff, page 146 about
MS NTLM authentication and SPNEGO. Its only a few lines though.
RFC 2478
Cheers,
Robert Welz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Daniel Patterson <da...@danpat.net>.
>
> No. Both https and mod_auth_digest are ways to send a plain text
> password securely. And this plain text password must be sent *every
> time*. I'm talking about some server component (e.g. an apache auth
> module) which would hand over temporary session tokens/credentials. An
> administrator would be able to configure the expiry time of these tokens
> (2 hours? 1 day? a week?).
Actually, using Basic auth over a HTTPS connection is kind of redundant,
as you can identify the client with a certificate. In this situation,
the communication is quite secure, and the password (the certificate)
never leaves the client machine.
The whole point of this discussion is to attempt to find a balance
between user convenience (it always "just knows" who the user is)
and security (there are no usable tokens left lying around).
IMO, the only real secure way would be to introduce some kind of
plug-innable hardware token that the user can unplug from their
client when finished, but that assumes a lot about where the client
is running and would be awfully hard to get right (and also the
fact that some malicious process might be able to query the hardware
token while it's plugged in).
What we're looking for is simply a convenience for users who aren't anal
about their
password (i.e. don't care if it's swapped to disc), but care
enough about it to not want it sitting (even obfuscated) around
permanently where it can be tinkered with when they're not around.
If you want a "100% secure" authentication scheme, then these
discussions need to head down a very different path.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>> The svnserve+ssh combo already has its own "private" solution
>> (with ssh-agent).
>>
>> The point of this idea is to avoid having the client send a plaint
>> text password in each request. I don't see any way of dealing with
>> this in Apache other than with a modified auth module.
>
>
> mod_auth_digest? https://?
No. Both https and mod_auth_digest are ways to send a plain text
password securely. And this plain text password must be sent *every
time*. I'm talking about some server component (e.g. an apache auth
module) which would hand over temporary session tokens/credentials. An
administrator would be able to configure the expiry time of these tokens
(2 hours? 1 day? a week?).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Branko Čibej <br...@xbc.nu>.
Nicolás Lichtmaier wrote:
> The svnserve+ssh combo already has its own "private" solution (with
> ssh-agent).
>
> The point of this idea is to avoid having the client send a plaint
> text password in each request. I don't see any way of dealing with
> this in Apache other than with a modified auth module.
mod_auth_digest? https://?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
Branko Čibej wrote:
>>>> If there is to be any more discussion of agent programs, please
>>>> don't bastardise and clone the ssh-agent design -- as it does not
>>>> apply to passwords very well at all. I suspect if someone *really*
>>>> has some requirement to keep plaintext passwords off-disk, then
>>>> password authentication will be unsuitable for their environment in
>>>> the first place.
>>>
>>> So what's the alternative? Certificates and such usually require a
>>> passphrase, too -- and if they don't, they're quite as insecure as
>>> passwords.
>>
>> Probable long term solution?:
>>
>> Create a new authentication module for Apache.
>
> DAV isn't the only network transport for Subversion, so this isnt' a
> solution.
I know but:
The svnserve+ssh combo already has its own "private" solution (with
ssh-agent).
The point of this idea is to avoid having the client send a plaint
text password in each request. I don't see any way of dealing with this
in Apache other than with a modified auth module.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Branko Čibej <br...@xbc.nu>.
Nicolás Lichtmaier wrote:
>
>>> If there is to be any more discussion of agent programs, please
>>> don't bastardise and clone the ssh-agent design -- as it does not
>>> apply to passwords very well at all. I suspect if someone *really*
>>> has some requirement to keep plaintext passwords off-disk, then
>>> password authentication will be unsuitable for their environment in
>>> the first place.
>>
>>
>>
>> So what's the alternative? Certificates and such usually require a
>> passphrase, too -- and if they don't, they're quite as insecure as
>> passwords.
>
>
>
> Probable long term solution?:
>
> Create a new authentication module for Apache.
DAV isn't the only network transport for Subversion, so this isnt' a
solution.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>> If there is to be any more discussion of agent programs, please don't
>> bastardise and clone the ssh-agent design -- as it does not apply to
>> passwords very well at all. I suspect if someone *really* has some
>> requirement to keep plaintext passwords off-disk, then password
>> authentication will be unsuitable for their environment in the first
>> place.
>
>
> So what's the alternative? Certificates and such usually require a
> passphrase, too -- and if they don't, they're quite as insecure as
> passwords.
Probable long term solution?:
Create a new authentication module for Apache. This module could be a
modified version of mod_digest, which would return a "session token"
with successful logins. It would store these session tokens (along with
an expiration date) in the server. Future client request should send the
session token, the module would look-up it in its cache and voila! The
client would store the session token, which is much more secure: The
token it's only useful for subversion (important when svn is configured
to use passwords from some common source). The token expires in a day or
two, minimizing the damage. Of course, this just means moving the
credential storage from the client to the server.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Branko Čibej <br...@xbc.nu>.
David Wilson wrote:
> Branko Čibej wrote:
>
>> The only useful (yes, and I do mean useful, not feasible) way to
>> implement this is by havingan agent that stores passwords in memory,
>> like ssh-agent. Then "cache_passwords=ask" could become
>> "cache_passwords=agent", and could be the default.
>
>
> Having an agent program for plaintext passwords is not much more
> secure than holding them on disk in the first place. For one, unless
> very complicated networking is involved (eg. passing fds between
> processes), the agent program *must* release what it is securing in
> order for itself or the data to be of any use. In other words, a user
> with suitable priviledges can access the password just as easily as
> before.
Any user with "suitable privileges" can get at your password no matter
what you do, even if you don't cache it anywhere.
> An agent program also introduces the following (especially on Windows):
*sigh* ... I'm so tired of "experts" who keep guessing about what
Windows can or can't do.
> if the system pages the process out, your password will end up *on
> disk* somewhere that is *inaccessable*, so even if you knew the
> process got paged, you couldn't scrub the disk.
The solution to this particular problem is, of course, to store the data
in non-pageable memory, something Windows can do just fine (not to
mention that, on Windows, you can encrypt the data using a user- and
session-specific key, so even if someone else can read the memory, they
can't decrypt the data).
> If there is to be any more discussion of agent programs, please don't
> bastardise and clone the ssh-agent design -- as it does not apply to
> passwords very well at all. I suspect if someone *really* has some
> requirement to keep plaintext passwords off-disk, then password
> authentication will be unsuitable for their environment in the first
> place.
So what's the alternative? Certificates and such usually require a
passphrase, too -- and if they don't, they're quite as insecure as
passwords.
>> This would be a useful thing to have, although IIRC some people
>> object to this on the grounds of it being too complex.
>
> There are plenty of security books out there (eg. Writing Secure Code)
> that would tell you it is a very bad thing. In my opinion, the current
> practice of the Subversion folk is the ideal one - leave the
> complicated security (certificates, public keys, encryption, etc) to
> other people *who know what they are doing*.
The trouble is, of course, that they usually don't.
> Trying to do it in an ad-hoc fashion like the attempt above will only
> lead us down a very windy and dangerous path.
"Windy" indeed. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Travis P <sv...@castle.fastmail.fm>.
On Jan 7, 2005, at 11:38 AM, David Wilson wrote:
> Branko Čibej wrote:
>
>> The only useful (yes, and I do mean useful, not feasible) way to
>> implement this is by havingan agent that stores passwords in memory,
>> like ssh-agent. Then "cache_passwords=ask" could become
>> "cache_passwords=agent", and could be the default.
>
> Having an agent program for plaintext passwords is not much more
> secure than holding them on disk in the first place.
> In other words, a user with suitable priviledges can access the
> password just as easily as before.
Suitable privileges to what? It might be the case for you that disk
and memory both have the same root/admin type user, but not in other
situations, including my own. The people with admin access to the
various AFS cells on my company's intranet (which include my home
directory) do not have root access to my machine. People with root
access to my machine do not have AFS admin privileges. Speaking about
"on disk" is too general -- which disk, local or remote? The cached
passwords may be stored on a different disk (remote) than that to which
memory is swapped (local), which you also mentioned. Admittedly, the
people with root access to my machine could gain my credentials for my
AFS access. However, the AFS admin people would generally be
hard-pressed to get root access. Keeping the plaintext credentials off
something like an AFS/NFS disk is one of the reasons this issue comes
up, so my points are relevant.
> An agent program also introduces the following (especially on
> Windows): if the system pages the process out, your password will end
> up *on disk* somewhere that is *inaccessable*, so even if you knew the
> process got paged, you couldn't scrub the disk.
OS-specific techniques can often be used to prevent swapping to disk of
certain sensitive data. When possible that the sensitive data be kept
in RAM, that eliminates a class of attacks where the password can be
discovered (say by someone who must unplug your computer to steal it
and who will then attack the computer via a root compromise). There
still might be some window of susceptibility (when the password is
used, it may be copied into swappable-RAM for a short period of time),
but the desire here is to minimize exposure, not eliminate it.
> If there is to be any more discussion of agent programs, please don't
> bastardise and clone the ssh-agent design -- as it does not apply to
> passwords very well at all. I suspect if someone *really* has some
> requirement to keep plaintext passwords off-disk, then password
> authentication will be unsuitable for their environment in the first
> place.
Given your lack of imagining my case above, I don't think your
conclusions here are necessarily true either.
> There are plenty of security books out there (eg. Writing Secure Code)
> that would tell you it is a very bad thing. In my opinion, the current
> practice of the Subversion folk is the ideal one - leave the
> complicated security (certificates, public keys, encryption, etc) to
> other people *who know what they are doing*. Trying to do it in an
> ad-hoc fashion like the attempt above will only lead us down a very
> windy and dangerous path.
Security systems have to interface with the programs that use them at
some point of course. I've very glad that Subversion uses neon and
Apache to handle the my client & server certificate secured connection,
but the password for my client certificate (or a decrypted version of
the certificate) certainly has to come from somewhere. Right now I
either type the password with every svn command or it lives unsecured,
cached on a remote disk. In my case, I consider tendonitis worse than a
cached client password on a remote disk. The security people may
disagree. The available solutions may be improveable. I disagree with
your encouragement not to try.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by David Wilson <dw...@botanicus.net>.
Branko Čibej wrote:
> The only useful (yes, and I do mean useful, not feasible) way to
> implement this is by havingan agent that stores passwords in memory,
> like ssh-agent. Then "cache_passwords=ask" could become
> "cache_passwords=agent", and could be the default.
Having an agent program for plaintext passwords is not much more secure
than holding them on disk in the first place. For one, unless very
complicated networking is involved (eg. passing fds between processes),
the agent program *must* release what it is securing in order for itself
or the data to be of any use. In other words, a user with suitable
priviledges can access the password just as easily as before.
An agent program also introduces the following (especially on Windows):
if the system pages the process out, your password will end up *on disk*
somewhere that is *inaccessable*, so even if you knew the process got
paged, you couldn't scrub the disk.
If there is to be any more discussion of agent programs, please don't
bastardise and clone the ssh-agent design -- as it does not apply to
passwords very well at all. I suspect if someone *really* has some
requirement to keep plaintext passwords off-disk, then password
authentication will be unsuitable for their environment in the first place.
>
> This would be a useful thing to have, although IIRC some people object
> to this on the grounds of it being too complex.
There are plenty of security books out there (eg. Writing Secure Code)
that would tell you it is a very bad thing. In my opinion, the current
practice of the Subversion folk is the ideal one - leave the complicated
security (certificates, public keys, encryption, etc) to other people
*who know what they are doing*. Trying to do it in an ad-hoc fashion
like the attempt above will only lead us down a very windy and dangerous
path.
Cheers,
David.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Tobias Ringström wrote:
>
>> The issue is whether Subversion should cache passwords by default or
>> not. I still feel that it should not for the reasons I stated earlier
>> in this thread, but I'm also beginning to realize, much to my
>> surprise, that I'm pretty alone with that opinion.
>
>
> FWIW, I agree with you that passwords should not be cached unless
> someone makes a positive choice to do so. However, that _is_ a change
> in behavior, both from the way that Subversion has acted until now, as
> well as how cvs pserver client works (if you count `cvs login`).
>
> How about a patch that does several things:
>
> 1) sets the default to cache=no
>
> 2) permits the following config settings:
> cache_passwords = no
> cache_passwords = yes
> cache_passwords = ask
I don't understand the usefulness of the last option.
> 3) permits some form of cached password expiration control, e.g. by
> timestamp (ask only once per hour) or something equally clever (ask
> every 42 commits?).
The only useful (yes, and I do mean useful, not feasible) way to
implement this is by havingan agent that stores passwords in memory,
like ssh-agent. Then "cache_passwords=ask" could become
"cache_passwords=agent", and could be the default.
This would be a useful thing to have, although IIRC some people object
to this on the grounds of it being too complex.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Philip Martin <ph...@codematters.co.uk>.
John Peacock <jp...@rowman.com> writes:
> How about a patch that does several things:
>
> 1) sets the default to cache=no
I like that.
>
> 2) permits the following config settings:
> cache_passwords = no
> cache_passwords = yes
> cache_passwords = ask
Is that an extension to the existing store-passwords boolean?
> 3) permits some form of cached password expiration control, e.g. by
> timestamp (ask only once per hour) or something equally clever (ask
> every 42 commits?).
That's overkill as far as I am concerned.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by John Peacock <jp...@rowman.com>.
Tobias Ringström wrote:
> The issue is
> whether Subversion should cache passwords by default or not. I still
> feel that it should not for the reasons I stated earlier in this thread,
> but I'm also beginning to realize, much to my surprise, that I'm pretty
> alone with that opinion.
FWIW, I agree with you that passwords should not be cached unless
someone makes a positive choice to do so. However, that _is_ a change
in behavior, both from the way that Subversion has acted until now, as
well as how cvs pserver client works (if you count `cvs login`).
How about a patch that does several things:
1) sets the default to cache=no
2) permits the following config settings:
cache_passwords = no
cache_passwords = yes
cache_passwords = ask
3) permits some form of cached password expiration control, e.g. by
timestamp (ask only once per hour) or something equally clever (ask
every 42 commits?).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Michael W Thelen <mi...@pietdepsi.com>.
Ben Collins-Sussman wrote:
>> No, you're not alone. I don't like programs that silently spread my
>> passwords in different files on my hard drive without me noticing. There
>> are ways to avoid this, but if I am just a little bit ignorant... I don't
>> see why changing a default would be bad. Scripts can hardly rely on this
>> config option set to a specific value, so it can't break compability.
>> I am
>> actually +1 on changing the default. This also sends a signal that we are
>> taking security seriously.
>
> I'd be okay with this also.
>
> But we'd better be ready for a slew of newbies asking us how to make
> subversion stop asking for their password. I predict it will jump into
> the top 10 FAQs on the users@ list.
>
> We may be gaining more security by default, but we're trading it for a
> chunk of convenience and user-friendliness.
Yes, although if the default is changed, the way for a user to change
Subversion's behavior becomes easier. Currently you must either edit a
config file (perhaps painful and/or confusing for the average user) or
remember to pass --no-auth-cache for every command, every time
(virtually impossible).
If the default changes, you may simply have to pass an --auth-cache flag
*once* for any command requiring authentication (easy, once you know
it's there). The FAQ answer becomes "Pass --auth-cache once and
Subversion will stop asking for your password" rather than "Find the
Subversion config file and edit it to turn off credential caching".
Subversion could even display such a message after a successful password
prompt, so the FAQ is answered immediately. (This may be considered too
distracting or may break output compatibility rules, though.) Something
like this:
$ svn ls http://example.com/repos
Username: joe
Password: *********
Use --auth-cache if you want Subversion to remember your password.
... rest of the output ...
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
Re: Feature Request: clients shouldn't store auth-creds
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> The more disturbing scenario is that people (or distributions) stay at
> svn 1.1 because of a perceived decrease in the usability of 1.2.
>
> I am not gung-ho about changing the default at all. My reasoning is
> that application-specific passwords are fairly bad security devices to
> start with. Failing to cache them by default would be trying to make up
> for their weaknesses by imposing policies which users won't tolerate.
> We wouldn't be increasing practical security very much and we'd be
> pissing off users more.
I pretty much agree with Greg.
Everyone will just set their configuration to cache authn info anyway
(after getting annoyed and taking the time to figure that out), and
we'll be right back where we were before. Except that now we'll be
able to point our fingers at the users and say "See, they chose to do
it, so it's their responsibility now."
End result: a moment of annoyance, a bootless shifting of blame, and
basically the same security people had before.
I think it's better to simply document authn caching, as we do, and
let the security-conscious turn it off if they want.
(Of course, when I say "everyone", I'm exaggerating. I just mean the
vast majority of users.)
> I am particularly concerned about changing the default in 1.x, because
> of the potential for our users to see it as a downgrade.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, January 5, 2005 4:17 PM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> The more disturbing scenario is that people (or distributions) stay at
> svn 1.1 because of a perceived decrease in the usability of 1.2.
>
> I am not gung-ho about changing the default at all. My reasoning is
> that application-specific passwords are fairly bad security devices to
> start with. Failing to cache them by default would be trying to make up
> for their weaknesses by imposing policies which users won't tolerate.
> We wouldn't be increasing practical security very much and we'd be
> pissing off users more.
>
> I am particularly concerned about changing the default in 1.x, because
> of the potential for our users to see it as a downgrade.
My thoughts exactly: I'd be fine with altering this in 2.0 (preferably with
a bundled svn-agent a la ssh-agent), but certainly not for 1.x. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by John Pybus <jo...@pybus.org>.
Greg Hudson wrote:
> On Wed, 2005-01-05 at 15:39, Ben Collins-Sussman wrote:
>
>
> The more disturbing scenario is that people (or distributions) stay at
> svn 1.1 because of a perceived decrease in the usability of 1.2.
If distros are worried enough to consider not upgrading (I find this
hard to believe given the compelling features still going into svn),
then they can change the default back in their packages. Likewise
sysads building from source probably have enough nous to change a config
file if they don't like the default rather than forgo the upgrade.
Maybe I misunderestimate folks.
> I am not gung-ho about changing the default at all. My reasoning is
> that application-specific passwords are fairly bad security devices to
> start with. Failing to cache them by default would be trying to make up
> for their weaknesses by imposing policies which users won't tolerate.
> We wouldn't be increasing practical security very much and we'd be
> pissing off users more.
Mot users I come across aren't really aware that they have
application-specific passwords. They have a password (maybe two) which
they only deviate from (by as little as possible) if password validation
when they first get an account refuses to accept it. Given this, not
doing our best to protect user passwords creates large risks of further
penetration once an unprotected password is discovered.
> I am particularly concerned about changing the default in 1.x, because
> of the potential for our users to see it as a downgrade.
On the other hand, gaining a reputation for bad security by the time you
get round to 2.0 wouldn't be a good thing either.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-01-05 at 15:39, Ben Collins-Sussman wrote:
> But we'd better be ready for a slew of newbies asking us how to make
> subversion stop asking for their password. I predict it will jump into
> the top 10 FAQs on the users@ list.
The more disturbing scenario is that people (or distributions) stay at
svn 1.1 because of a perceived decrease in the usability of 1.2.
I am not gung-ho about changing the default at all. My reasoning is
that application-specific passwords are fairly bad security devices to
start with. Failing to cache them by default would be trying to make up
for their weaknesses by imposing policies which users won't tolerate.
We wouldn't be increasing practical security very much and we'd be
pissing off users more.
I am particularly concerned about changing the default in 1.x, because
of the potential for our users to see it as a downgrade.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 5 Jan 2005, Ben Collins-Sussman wrote:
>
> On Jan 5, 2005, at 2:19 PM, Peter N. Lundblad wrote:
>
> We may be gaining more security by default, but we're trading it for a
> chunk of convenience and user-friendliness.
>
Isn't that the usual tradeoff? Keeping your door always unlocked is more
conveinent because you don't need to keep a car:-)
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by kf...@collab.net.
John Pybus <jo...@pybus.org> writes:
> I have a fairly strongly held view that end users have a right to
> expect that software will be secure by default. It is usually only
> the application developers who know enough about the systems they're
> creating to ask the right questions, and they should do so on behalf
> of their users.
True. But, if someone is prompted for a password the first time they
commit, and then never prompted again, it is pretty darned obvious
that the password is being cached *somewhere*. It doesn't take a
rocket scientist, as they say :-).
Once someone realizes that, the documentation about it is pretty easy
to find, so it's easy for them to tweak their configuration if they
want.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by John Pybus <jo...@pybus.org>.
Ben Collins-Sussman wrote:
>
> On Jan 5, 2005, at 2:19 PM, Peter N. Lundblad wrote:
>
>> I am
>> actually +1 on changing the default. This also sends a signal that we are
>> taking security seriously.
>>
>
> I'd be okay with this also.
>
> But we'd better be ready for a slew of newbies asking us how to make
> subversion stop asking for their password. I predict it will jump into
> the top 10 FAQs on the users@ list.
I'm sure it would, but I too think it'd be worth it anyway. The default
isn't too hard to change and people will at least have had the
opportunity to think about the trade-off they're making, even if most
still change the setting and forget about it. If it proves a big issue
then the password prompt can be made to give advise about the reason it
keeps appearing, and how to stop it.
> We may be gaining more security by default, but we're trading it for a
> chunk of convenience and user-friendliness.
Certainly convenience. Whether it is actually friendly to your users
(particularly those unfamiliar enough with subversion or security issues
to wonder what's happening to their password) to store their passwords
in plain text on any computer they happen to be working on is a matter
of debate.
I have a fairly strongly held view that end users have a right to expect
that software will be secure by default. It is usually only the
application developers who know enough about the systems they're
creating to ask the right questions, and they should do so on behalf of
their users.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 2:19 PM, Peter N. Lundblad wrote:
> On Wed, 5 Jan 2005, Tobias Ringström wrote:
>
>> kfogel@collab.net wrote:
>>
>> But the thread has drifted far away from it's origin. The issue is
>> whether Subversion should cache passwords by default or not. I still
>> feel that it should not for the reasons I stated earlier in this
>> thread,
>> but I'm also beginning to realize, much to my surprise, that I'm
>> pretty
>> alone with that opinion.
>>
> No, you're not alone. I don't like programs that silently spread my
> passwords in different files on my hard drive without me noticing.
> There
> are ways to avoid this, but if I am just a little bit ignorant... I
> don't
> see why changing a default would be bad. Scripts can hardly rely on
> this
> config option set to a specific value, so it can't break compability.
> I am
> actually +1 on changing the default. This also sends a signal that we
> are
> taking security seriously.
>
I'd be okay with this also.
But we'd better be ready for a slew of newbies asking us how to make
subversion stop asking for their password. I predict it will jump into
the top 10 FAQs on the users@ list.
We may be gaining more security by default, but we're trading it for a
chunk of convenience and user-friendliness.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 5 Jan 2005, Tobias Ringström wrote:
> kfogel@collab.net wrote:
>
> But the thread has drifted far away from it's origin. The issue is
> whether Subversion should cache passwords by default or not. I still
> feel that it should not for the reasons I stated earlier in this thread,
> but I'm also beginning to realize, much to my surprise, that I'm pretty
> alone with that opinion.
>
No, you're not alone. I don't like programs that silently spread my
passwords in different files on my hard drive without me noticing. There
are ways to avoid this, but if I am just a little bit ignorant... I don't
see why changing a default would be bad. Scripts can hardly rely on this
config option set to a specific value, so it can't break compability. I am
actually +1 on changing the default. This also sends a signal that we are
taking security seriously.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
kfogel@collab.net wrote:
>Tobias Ringström <to...@ringstrom.mine.nu> writes:
>
>
>>Nobody uses CVS passwords because it is so insecure. Instead, most
>>people run CVS via ssh which does not store passwords. It's not a fair
>>comparison.
>>
>>
>I don't believe this assertion is true, and would like to see the data
>that backs it up :-).
>
>
OK, I can concede that "nobody" was at least a slight overstatement
here. :-)
But the thread has drifted far away from it's origin. The issue is
whether Subversion should cache passwords by default or not. I still
feel that it should not for the reasons I stated earlier in this thread,
but I'm also beginning to realize, much to my surprise, that I'm pretty
alone with that opinion.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by kf...@collab.net.
Tobias Ringström <to...@ringstrom.mine.nu> writes:
> Nobody uses CVS passwords because it is so insecure. Instead, most
> people run CVS via ssh which does not store passwords. It's not a fair
> comparison.
I don't believe this assertion is true, and would like to see the data
that backs it up :-).
True, many security-conscious sites these days do insist on
CVS-over-SSH. But plenty still use plain old pserver, shocking as
that may sound. I haven't done a formal study, but I don't think
pserver is vanishing as rapidly as you imply.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Tobias Ringström:
> Nobody uses CVS passwords because it is so insecure. Instead, most
> people run CVS via ssh which does not store passwords. It's not a fair
> comparison.
I think the reason is that people are afraid of the pserver
implementation. 8-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Ben Collins-Sussman wrote:
> On Jan 3, 2005, at 5:03 PM, Tobias Ringström wrote:
>
>> Subversion is pretty unique in that it stores passwords by default.
>
> Doesn't CVS do this?
No, you run "cvs login" which has to store the password for obvious
reasons. But it's an irrelevant comparison, because CVS passwords are
not used over the Internet which is where security matters most. See below.
>> On top of that, it also stores them in plain text,
>
> Doesn't CVS do this?
No, the password is scrambled which is of course not secure, but it does
provide glance-over-shoulder "security".
> I'm not saying that CVS doing something means it's a Good Thing. :-)
Certainly not. :-)
> I'm guessing, though, that not many people are surprised by this
> particular behavior, because CVS does it. Notice that this is the
> first time we've heard complaints about "caching by default".
Nobody uses CVS passwords because it is so insecure. Instead, most
people run CVS via ssh which does not store passwords. It's not a fair
comparison.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 3, 2005, at 5:03 PM, Tobias Ringström wrote:
> Subversion is pretty unique in that it stores passwords by default.
Doesn't CVS do this?
> On top of that, it also stores them in plain text,
Doesn't CVS do this?
I'm not saying that CVS doing something means it's a Good Thing. :-)
I'm guessing, though, that not many people are surprised by this
particular behavior, because CVS does it. Notice that this is the
first time we've heard complaints about "caching by default".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, December 29, 2004 12:05 AM +0100 Tobias Ringström
> <to...@ringstrom.mine.nu> wrote:
>
>> Anyway, that's a side track. Your point that Subversion should not cache
>> passwords by default is convincing, especially since we now have a knob
>> to control just that. I'll think about it some more and look into it.
>
> We shouldn't be changing defaults like that until 2.0. If a user
> wants to not cache passwords, the user only needs to change their
> ~/.subversion/config file. I don't see the problem here. -- justin
I think you're being overly conservative, because we have changed a lot
of defaults before. Just to mention a few such changes in 1.1.0, we made
"svnadmin recover" non-blocking, increased a neon timeout, started to
process svn:externals in defined order, and changed the default pegging.
All of them were changed for a good reason, of course. Why would this
change be different?
The good reason in this case is to behave more securely out of the box.
People how upgrade will not be hit very hard because their passwords
will still be cached. Only new credentials would be affected. Subversion
is pretty unique in that it stores passwords by default. On top of that,
it also stores them in plain text, and there is no good way to "forget"
passwords. I think a change would be a clear improvement, but I'm
certainly open to other opinions.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, December 29, 2004 12:05 AM +0100 Tobias Ringström
<to...@ringstrom.mine.nu> wrote:
> Anyway, that's a side track. Your point that Subversion should not cache
> passwords by default is convincing, especially since we now have a knob
> to control just that. I'll think about it some more and look into it.
We shouldn't be changing defaults like that until 2.0. If a user wants to
not cache passwords, the user only needs to change their
~/.subversion/config file. I don't see the problem here. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Robert wrote:
> I enabled apache's digest auth and worked with some wc's on three
> machines until sudden where I realized that svn didn't ask me twice
> for a password. Then I searched around and find ~/subversion/config
> where the hint was given to change store-auth-creds and to remove already
...you're used to have to enter the password twice (and you're not using
svn+ssh://)...
> stored credentials inside each .svn directory. I didn't work that out
> so I finally committed outstanding changes of the wc's and deleted
> them to check them out again (with store-auth-creds=no).
...and you had to delete the WCs... Hmm... You're not using an ancient
version of Subversion, are you? The credentials used to be stored in the
working copies, but that was a very long time ago.
Anyway, that's a side track. Your point that Subversion should not cache
passwords by default is convincing, especially since we now have a knob
to control just that. I'll think about it some more and look into it.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Robert <ro...@gmx.de>.
Hello!
In my last posting in this thread I forgot:
Maybe one could add a command line option for ./configure like
--enable-store-passwords
Greetings,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Robert <ro...@gmx.de>.
Am 27.12.2004 um 23:29 schrieb Tobias Ringström:
>> I have a DMZ with Web Server on which I work with svn for the web
>> pages and today decided to enforce digest auth in apache.conf. But
>> for other users (the clients) in a corporate network it is very
>> confusing. Since those people normally are no admins it doesn't make
>> sense.
>>
>> And it took me hours to change every working copy and the config on
>> all my accounts. On the other side enabling caching would be much
>> faster.
>
> I don't understand what you are saying here. Why did you have to
> change the working copies?
Hello.
I enabled apache's digest auth and worked with some wc's on three
machines until sudden where I realized that svn didn't ask me twice for
a password. Then I searched around and find ~/subversion/config where
the hint was given to change store-auth-creds and to remove already
stored credentials inside each .svn directory. I didn't work that out
so I finally committed outstanding changes of the wc's and deleted them
to check them out again (with store-auth-creds=no).
Setting store-auth-creds (or store-passwords which looks better) to no
by default would give more security by enforcing some sec policy where
user who really want can change that later although they shouldn't.
Remember my example some developer's account gets hacked and the
intruder commits lots of rubbish into the repository. Poor admin and
poor filesystem since the database could grow until the partition is
full.
I would suggest creating /etc/subversion/config and no
~/subversion/config with store-passwords=no as default becourse a rigid
security policy is best. Users are usually no experienced admins but
the should ask their admin if the environment is not comfortable
enough. On the other hand, if everything is comfortable no one will ask
leaving a big security hole to the subversion database.
Just my 3 ct's,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature Request: clients shouldn't store auth-creds
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Robert wrote:
> Hello.
> Would you please set store-auth-creds to no and uncomment that key
> please in ~.subversion/config.
I'd recommend setting store-passwords to no instead of store-auth-creds,
because setting store-auth-creds to no also disables Subversion's
ability to remember user names and to permanently trust server certificates.
> I have a DMZ with Web Server on which I work with svn for the web
> pages and today decided to enforce digest auth in apache.conf. But for
> other users (the clients) in a corporate network it is very confusing.
> Since those people normally are no admins it doesn't make sense.
>
> And it took me hours to change every working copy and the config on
> all my accounts. On the other side enabling caching would be much faster.
I don't understand what you are saying here. Why did you have to change
the working copies?
> In my opinion, security has to be enabled by default, if the password
> dialog is annoying for some user, he should decide on his own.
If you need that level of security and you cannot trust your users to
not cache the passwords, you can use client certificates instead. Client
certificate passwords are never cached by Subversion.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org