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

[Stefan Sperling <st...@elego.de>]

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.

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

> 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).

Stefan

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

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

[Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>]

2008-09-16 16:58:43 Mark Phippard napisał(a):
> Does GnuPG have any external dependencies?

libassuan
libgcrypt
libgpg-error
libksba
pth
${OPTIONAL_DEPENDENCIES}
${INTERNAL_CURL_REPLACEMENT:-curl}

-- 
Arfrever Frehtes Taifersar Arahesis

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

[Stefan Sperling <st...@elego.de>]

On Tue, Sep 16, 2008 at 10:58:43AM -0400, Mark Phippard wrote:
> On Tue, Sep 16, 2008 at 10:47 AM, Stefan Sperling <st...@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?

Yes, e.g. in a debugger -- just set a breakpoint at the decryption
routine and examine the variables.

But it would also be possible from a hex editor, without actually
running the binary.

What agents like KWallet, Gnome-Keyring, and gpg-agent buy
us is:

 1) The secret passed to the agent survives across invocations
    of svn, so the user is only promted once.

 2) The secret is not stored anywhere except in mlock()'d memory
    and the user's brain. Unless users write their passphrase to
    a post-it note on their monitor, of course, but that is their
    own fault.

The secret would be saved to a file in your approach, because it
would need to be stored inside the binary. Or we could prompt
the user for the secret, but then we might as well prompt for
the password itself :)

We could also implement our own svn-agent, but that would mean
re-inventing the wheel because there already is other high-quality
free and open source software we can use which was written for
this exact purpose.

> > 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.

That's why I suggested GPGME, because GnuPG-2 has an agent.

> Thanks.  I recall you had mentioned this was something you wanted to
> look at.  I was assuming you found some roadblocks.

No roadblocks. I just didn't have time.

> My understanding
> is that GPG-2 is a bit of a roadblock isn't it?  It is not very widely
> deployed yet is it?

It was released in 2006, see this announcement for details:
http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000239.html

Interesting quote from the anouncement:

 In fact, the gpg version from GnuPG-1 is able to make
 use of the gpg-agent as included in GnuPG-2 and allows
 for seamless passphrase caching.

So it looks like you could even get away with just the agent
and a recent enough version of GnuPG-1.

> 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.

I don't know. Support for GPGME has been an idea I've been tossing
around for a while, but I have not yet researched the topic in enough
depth to be able to answer these questions.

Stefan

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

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

[Mark Phippard <ma...@gmail.com>]

On Tue, Sep 16, 2008 at 10:47 AM, Stefan Sperling <st...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org