2009/8/31 Andy Levy <andy.levy_at_gmail.com>:
> On Sun, Aug 30, 2009 at 23:26, Nico Kadel-Garcia<nkadel_at_gmail.com> wrote:
>> 2009/8/30 wenk <gaowenk_at_yahoo.com.cn>:
>>> how can I change my password by SVN client??
>>> ________________________________
>>> 好玩贺卡等你发，邮箱贺卡全新上线！
>>
>> If your Subversion server allows password entry, then you should not
>> use it for anything you care about. The reference implementation of
>> Subversion has the clients store their passwords in clear text in
>> $HOME/.svn/auth/. Since this is clear never going to go away, it means
>> that the basic Subversion security model is broken.
>
> This has already been pointed out to you as NOT TUE.
>
> On Windows & OS X, Windows Crypto & OS X Keychain respectively are
> used to protect your password. On *NIX, If Gnome or KDE is installed,
> their "wallets" are used to save the password encrypted. It is
> ultimately left to the host system to set ACL policies appropriately
> so that other users can't access your sensitive files.
>
> If you really believe this is a security problem, I hope you're on the
> OpenSSH mailing list complaining that the use of SSH authorization
> keys is insecure because if someone gains access to my ~/.ssh
> directory, they can impersonate me.
Andy, I wrote the SunOS port of SSH 1, SSH 2, and OpenSSH years back.
So yes, I've been active on it for years. That approach is much
superior to the standard and limited SSH key access, which presents
day-to-day integration problems. It's why for most UNIX users in
professional environments, I recommend they use TortoiseSVN to a Samba
share to access their repositories. The client is much safer, and much
more reliable.
>> If your servers do not insist on using SSL key access or svn+ssh
>> access instead, then the server is not secure enough to be trusted and
>> you should refuse to use it, simply as a security conscious user.
>
> As noted previously, this is not true. All my clients use Windows, so
> the password is encrypted when cached. My server uses HTTP Digest
> authentication, so the password isn't in the clear over the wire. And
> my repository isn't accessible from outside the corporate firewall.
> It's plenty secure.
That's good. Like HTTPS transmission, it helps protect you from some
of the irritating net-sniffing or ARP poisoning attacks popular for
some crackers once they've gained access to your network. But security
is a layered issue: closing that window doesn't close the big hole of
the clear-text passwords. After all, are you *SURE* your clients don't
use UNIX, Linux, or CygWin tools that follow the old clear-text
security model? CygWin certainly does, even if your shop is all
Windows, and it's a very useful toolkit for build structures and open
source integration. How do you stop them from doing so? And if they
do, are you *sure* their passwords aren't in clear-text on backups, on
unsecured laptops, or that someone can't plug in a rootkitted laptop
or a botnet laden home machine on VPN?
Those are all real issues: reliance on the crunchy outer shell of
HTTPS encryption does not protect the soft, chewy underbelly of
plain-text stored passwords. And fixing it in Windows is a good step,
but I've had one heck of a time in each Subversion environment I've
set up (including 2 fiscal companies) that they cannot rely on
firewalls to protect data inside their networks. And I've dealt with
far, far too many academic environments in the last few decades where
"information should be free" was an excuse to lose months of work when
some cracker ran rampant through their internally very, very open
environments. (My first major security emergency was the Morris Worm.
It was nasty!)
I'm *delighted* security wallets are becoming more common, rather than
the $HOME/.svn/auth/ But the cavalier handling of such dangerous
resources, and the far too common "if you don't trust your machine,
you shouldn't develop on it" mindset leave too many people's source
repositories, and other accounts that they share the same password
with, open to quite serious abuse. I've seen several sites in the last
few years that not only use Active Directory based web access, so that
their Subversion passwords are their Windows user passwords, but which
refuse to move off of HTTP to HTTPS because "we trust the people we
work with".
Do I have a better solution? As an approach, I like Kerberized SSH
access for genuine "single-sign-on" for Windows and UNIX users.
Unfortunately, there is no "restricted user shell" for Subversion
access as there is for git, for example, so that is insufficient
unless you want all your Subversion users to have shell access to your
server and have to manage the file permissions via other means. So,
for now, I stick with svn+ssh to a shared user account whose
$HOME/.ssh/authorized_keys sets the user's logging name based on the
key: it's about as good as I can get in the UNIX/Linux world.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388875
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-31 14:17:49 CEST