Re: [RFC] - Custom Subversion library for encrypting cached passwords

On Tue, Sep 16, 2008 at 10:47 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Sep 16, 2008 at 10:08:15AM -0400, Mark Phippard wrote:
>> So what if we were to write a simple library for our auth system that
>> used one of these routines for encrypting data and we allowed the
>> "key" to be determined at ./configure time? Something like
>> --with-svn-key=MY_S3CR3T_K3Y. Would this be any more secure or is it
>> trivial to figure out the key that was used by looking at the binary?
>
> This would not be secure at all, no.

Because it would be trivial to determine the key from the binary?

> Also, I'd think you'd generally want secrets to be per-user,
> and not per-binary.

Definitely, I just cannot think of a way to do that without some kind
of agent where the user provides a passphrase.

>> It seems like if our routine combined this key with the current
>> username to encrypt the password it would be a reasonably secure
>> option for storing encrypted passwords that would work in environments
>> without a GUI. We could still give preference to the gnome and kde
>> options at runtime if they are available.
>
> I believe an additional auth cache provider based on GPGME
> (http://www.gnupg.org/gpgme.html) could solve your problems.
>
> Everyone using this would need a PGP key pair, the private
> part of which would be the secret used when encrypting and
> decrypting passwords and certificates saved to disk.
> This private PGP key can be protected by a passphrase.
>
> GnuPG-2 has an agent, which works much like ssh-agent.
> You enter your passphrase once, and the agent remembers it in
> locked RAM which will never go to swap. When encrypting/decrypting
> passwords, the GPGME library can talk to the agent to get
> at the passphrase to decrypt the private key and then use
> the private key to encrypt or decrypt the Subversion password
> or certificate.
>
> This should not require a GUI, because users can enter the
> passphrase via one of the 'pinentry' front-ends, various variants
> of which exist -- including an ncurses-based one, which runs in
> text mode.
>
> It is possible to set up PGP key pairs for exclusive use with
> Subversion, so people don't even have to use their regular
> PGP keys for this if they don't want to.
>
> As far as I can tell your only dependency then would be GnuPG-2,
> which may not be readily available on old UNIX and Linux systems,
> but should be installable from source. GnuPG-1.x is more widespread,
> but I have no idea if GPGME can use it.
>
> Once the PGP keys are set up and a gpg-agent is running, the usability
> should match that of KWallet and Gnome Keyring (which I believe use a
> "master password" instead of a PGP private key for the secret when
> encrypting/decrypting).

Thanks. I recall you had mentioned this was something you wanted to
look at. I was assuming you found some roadblocks. My understanding
is that GPG-2 is a bit of a roadblock isn't it? It is not very widely
deployed yet is it?

My ideal would be a solution that worked out of the box on something
like RHEL 4 which is still in wide use in Enterprises. Stepping back
to reality, I could live with something that could be provided
relatively easily on these OS. Does GnuPG have any external
dependencies? Can it be packaged for older distros relatively easily?
 Also think of things like Solaris, HP-UX and AIX.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org