Re: RFA: Encrypting auth info

Here's a transcript of my discussion on IRC with Ben about this.

        sussman <irc://irc.eu.freenode.net/sussman,isnick> brane: what I mean
is, rather than putting #ifdef win32 into libsvn_subr

        sussman <irc://irc.eu.freenode.net/sussman,isnick> why not just put
that into the build system

        brane huh?

        sussman <irc://irc.eu.freenode.net/sussman,isnick> if you're building
on win32, poof, you get these extra providers built

        sussman <irc://irc.eu.freenode.net/sussman,isnick> hm, I guess that's
no different.

        brane oh, that -- well yes, certainly, something alng the lines of the
bits in svn_config that fiddle with the registry

        sussman <irc://irc.eu.freenode.net/sussman,isnick> is there any way to
get crypted passwords on unix too?

        brane but then we'd suddenty have a different *API* on windows

        sussman <irc://irc.eu.freenode.net/sussman,isnick> or is win32 the
only api that makes this convenient?

        brane and we've never had one of those yet

        sussman <irc://irc.eu.freenode.net/sussman,isnick> mmmm

        brane i don't know about other oses

        brane on linux, i'd probably mount an encrypted file to
~/.subversion/auth through the loop device

        brane but that's equivaent to the ntfs encryption hack on Windows, and
doesn't always work

        brane i'd much rather see a generic API that lets the auth provider
say, "this bit of data is sensitive, do your best with it"

        brane on windows, we could use strong encryption

        brane on most unices, we could eventually be persuaded to ROT-13

        brane (really, all those who request this do have a point)

        brane althouth the false-sense-of-security argument still holds, of
course

        sussman <irc://irc.eu.freenode.net/sussman,isnick> yup, I've been
arguing for it for a long time.

        sussman <irc://irc.eu.freenode.net/sussman,isnick> but breser is
really against rot-13. :-)

        brane i understand his pov completely

        sussman <irc://irc.eu.freenode.net/sussman,isnick> maybe it could be a
run-time option, that the user chooses

        sussman <irc://irc.eu.freenode.net/sussman,isnick> "please rot-13 my
cache"

        sussman <irc://irc.eu.freenode.net/sussman,isnick> or something

        brane no

        brane if i write code that encrypts the password on disk, i definitely
don't want ti give the user a knob to turn that off

        sussman <irc://irc.eu.freenode.net/sussman,isnick> so unix folks
really have no equivalent.

        sussman <irc://irc.eu.freenode.net/sussman,isnick> no real crypto
available.

        brane sure they do

        brane openssl has it

        brane the difference is in the conriguration

        sussman <irc://irc.eu.freenode.net/sussman,isnick> ah.

        sussman <irc://irc.eu.freenode.net/sussman,isnick> so maybe svn could
learn to detect and use openssl.

        brane on windows, the crypto framework maintains a per-user symmetric
key in a "secure" place, so that the crypto functions don't have to ask
for passwords and such

        brane (it hangs off the login session)

        sussman <irc://irc.eu.freenode.net/sussman,isnick> it just makes me
sad to think that after so many requests for this feature, we're only
fixing it on one OS. :-/

        brane see, that's why i started this discussion

        sussman <irc://irc.eu.freenode.net/sussman,isnick> I wish APR were
doing this

        brane if we design our api correctly, then a packager can set up real
encryption with the correct *compile time* options

        brane yes, well, apr isn't

        sussman <irc://irc.eu.freenode.net/sussman,isnick> can you elaborate?

        sussman <irc://irc.eu.freenode.net/sussman,isnick> with some
hypothetical examples?

        brane let's suppose we have an encrypt/decrypt pair

        brane and compile-time configuration to select the implementation
(crypto provider)

        brane on windows, of course, there's nothing to decide about

        brane on unix, we could supply a no-op and rot-13 provider

        brane (don't want to go into selecting defaults yet)

        sussman <irc://irc.eu.freenode.net/sussman,isnick> ah.

        brane a bright boy at RedHat could, for example, do some PAM magic
that unlocks a user-specific key when you log in

        brane and compile in a special provider that could use that key

        sussman <irc://irc.eu.freenode.net/sussman,isnick> ahhhh

        sussman <irc://irc.eu.freenode.net/sussman,isnick> so, can you
followup to the dev@ mail with these excellent hypothetical ideas?

        sussman <irc://irc.eu.freenode.net/sussman,isnick> this is what I was
looking for

        brane i think i'll just paste a transcript

Branko Čibej wrote:

> Well, here I am, opening this issue again myself.
>
> It turns out that, for some applications, having encrypted auth data
> would be a Good Thing indeed. The situation I'm specifically looking
> at is this:
>
> * Most developers in a company have Windows boxes on their desks
> * Most Subversion servers are Unix boxes of one flavour or another
> * Everyone wants to use thir Windows password to access the SVN
> repositories
>
> So, your friendly neighbour administrator teaches the Apaches on the
> Unixen (via pam_smb, pam_winbindd, pam_ldap, or whatever) to
> authenticate against a Windows domain or Active Directory.
>
> The trouble is, now, that everybody's Windows password gets stored in
> plaintext in their Subversion config area. Same friendly administrator
> gets the bright idea to encdypt (using filsystem encryption) the auth
> area. But... some people don't or can't use NTFS; some of the user
> config areas are in fact mounted on Samba shares.
>
> Luckily for said administrator, the Win32 CryptoAPI provides functions
> for encrypting and decrypting thata with a session key that Windows
> magically associates with the logged-on user. So he gets the bright
> idea to add generic encryption support to the svn auth functions. (And
> I really _do_ mean encryption, not som ROT-13 obfuscation scheme.)
>
> End of story, and here's the question:
>
> I basically see two ways to go about this:
>
> * modify svn_config_(read|write)_auth_data to crypt everything, thus
> localising the change in those functions, or define a second set
> of config read/write functions that encrypt the data
> * add encryption functions to libsvn_subr, and let the auth
> providers use them as they see fit.
>
> If I decide on the second solution, I'd initially only encrypt the
> passwords stored by the simple auth provider, and perhaps later for
> the cert_pw provider. In any case, I don't propose to add a full-blown
> crypto API to Subversion.
>
> I think doing it this way would be better and simpler than writing
> some kind of svn agent to store plaintext passwords, and would
> certainly be less intrusive.
>
> So: Any suggestions or ideas?
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org