You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2008/09/16 14:08:15 UTC
[RFC] - Custom Subversion library for encrypting cached passwords
Our trunk code includes two nice new options for storing passwords in
an encrypted form on *nix OS. These are the gnome-keyring and kwallet
options. Unfortunately, both of these options suffer from two major
problems that limits their usefulness as a "final" solution to this
problem:
1. They both require fairly recent versions of dependencies, so cannot
be easily used on say RHEL 4 as an example, but probably some Unix
derivatives as well.
2. They require a GUI so do not work with working on a remote *nix
host via Terminal.
The latter is obviously the bigger problem. I've posted about this
here [1], and got no response.
There are obviously a number of ways to encrypt and store a string
that are readily available to us to use. My understanding of why we
have not tried this option is that these methods all require providing
some kind of "key" to the encryption routine so that it can be used to
encrypt and decrypt the string. Given that we are open source, this
"key" would be easy for anyone to discover and then write an equally
simple cracker program to decrypt the string.
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?
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.
[1] = http://svn.haxx.se/dev/archive-2008-09/0162.shtml
--
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
Re: [RFC] - Custom Subversion library for encrypting cached passwords
Posted by 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
Posted by 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
Posted by 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
Re: [RFC] - Custom Subversion library for encrypting cached
passwords
Posted by 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
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Tue, Sep 16, 2008 at 10:08 AM, Mark Phippard <ma...@gmail.com> 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?
It would likely be pretty easy to write a tool that would extract the
secret key from the binary.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org