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

RFA: Encrypting auth info

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-02-16 04:33:26 CET

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
Received on Wed Feb 16 04:32:33 2005

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