On Tue, Sep 16, 2008 at 10:58:43AM -0400, Mark Phippard wrote:
> 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?
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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-16 17:58:32 CEST