[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: C# SVN Encrypted Authentication wrapper for Windows and svnserve.exe

From: DARKGuy . <dark.guy.2008_at_gmail.com>
Date: Fri, 29 Aug 2014 14:55:49 -0430

Hello again Brane,

I guess it deneds more on who manages the server in this case. In
mine, I needed to set up a simple, portable SVN server in my work
computer, which, by enterprise policies, makes my whole C: drive
available to my manager and tech support staff, and because I greatly
dislike this kind of access, if the case of someone random copying the
files from my computer, they wouldn't get the repository passwords so
easily at least.

In my solution, the passwords to encrypt the "passwd" file can be
hardcoded (though I know it isn't a good idea, but it's better than
plain text passwords...) inside the DLL file and made harder to read
unless they use a decompiler or other kind of tools, which aren't very
known to that kind of people in my country, and that makes me feel
safer.

I don't get your point though, it's like saying that if lockpicks,
hammers, etc. exist then why to buy an expensive lock for your home?
better leave it open so everyone can get in... that's what I
understand from what you say. SASL may be good, but it doesn't
contrast to the portability that the svnserve.exe binary makes itself
proud of (that is, installing something OS-wide (which some restricted
users don't have access to) and involving registry keys). My (working)
proposal is something that circumvents those restrictions and gives an
alternative to that method, although not as secure, but again, better
than storing the password in plain text out there in the wild.

Either way thanks for taking a look at it at least, I hadn't read you
are the Subversion director until I received your reply :P

- DARKGuy

On Fri, Aug 29, 2014 at 2:40 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 29.08.2014 20:50, DARKGuy . wrote:
>
> Hello,
>
> Sorry, I was not subscribed before I sent this message, I'm more used
> to forums and other kind of software than mailing lists, so excuse my
> lack of netiquette in this aspect. I put the same email subject and
> history in here hoping the mailing list software will catch up with
> it.
>
> About the project I wanted to announce here, I don't know what kind of
> discussion is Branko talking about, but anything else is better than
> plaintext passwords, even if it's a simple base64 cipher (which in my
> case is Rijndael).
>
> It's curious how someone invests time in making something useful for
> the community gets such a bad reception, nice way to welcome someone,
> heh.
>
>
> You can begin here:
>
> http://en.wikipedia.org/wiki/Security_through_obscurity
>
> The bottom line is that your proposal does exactly nothing to secure the
> passwords, all it does is give naïve admins a false sense of security. This
> is known to be worse than the cure.
>
> For example, an admin who knows that she has plaintext passwords on disk
> will (hopefully) take measures to protect them, by protecting access to the
> machine itself, by carefully controlling access rights to the password file,
> etc. ... or by using SASL. An admin who thinks her passwords are encrypted
> may not take such precautions.
>
> In the case of your proposed solution, anyone who has access to the server
> can eventually read the plaintext password file, without even having to take
> the trouble of trying to decrypt it.
>
>
> Anyways, I hope it ends up being useful for someone who doesn't mind
> having a little bit of security, even if it's through "obscurity" or
> whatever you're talking about...
>
>
> "A little bit of security," as you put it ... is no security at all, as I
> explained above. That the default password file for CRAM-MD5 authentication
> in svnserve is in the clear is no accident: it is the result of a conscious
> decision to not try to invent custom security protocols, because the results
> are invariably disastrous. That is why we support SASL instead, which has
> been reviewed and verified any number of times. It may be a hassle to set up
> on Windows, but there are no simple point-and-click solutions to securing a
> server.
>
> -- Brane
>
>
> ---
> From: Branko ÄŒibej <brane_at_wandisco.com>
> Date: Fri, 29 Aug 2014 15:31:18 +0200
>
> On 29.08.2014 15:04, DARKGuy . wrote:
>
> Hey all :)
>
> I'm really proud to announce a small app I wrote located here ->
> https://github.com/darkguy2008/SVNEncryptedAuth <- that will hook into
> the svnserve.exe process and encrypt the passwords located in the
> "passwd" file, while making it use a temporary file with the plaintext
> passwords on access (deleted almost immediately for security).
>
> This is made so the passwords don't get stored in plaintext but with
> some sort of encryption. I don't know why this wasn't planned in the
> release of that app, since we all know plaintext passwords are BAD and
> SASL is a pain to set up under Windows (also, not portable since it
> requires registry keys) and since I don't want to go with the hassle
> of downloading the source code and compiling the whole thing,
> developing an IAT hook patch was easier to do.
>
> I hope you guys like the project and becomes useful for anyone here.
>
> Comments & suggestions welcome, thanks!
> - DARKGuy
>
> Do we really have to go through the whole "security through obscurity"
> discussion again?
>
> -- Brane
>
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco | Realising the impossibilities of Big Data
> e. brane_at_wandisco.com
Received on 2014-08-29 21:26:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.