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

Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 6 Apr 2012 10:47:58 -0400

On Apr 6, 2012 10:36 AM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
>
> On 04/06/2012 04:22 AM, Greg Stein wrote:
> > Yeah, I switched the master passphrase param to an svn_string_t on the
> > probable outcome that we would immediately SHA1 the thing, and then use
the
> > resulting hash as the nominal password. That would avoid having the
> > plaintext in memory (and yes, I recognize it is quite possible that
other
> > copies exist; gotta start somewhere, and provide a data flow that
avoids the
> > requirement of plaintext).
>
> To be clear, Greg, you're talking about something a little bit than
Brane's
> "whole-disk encryption via encrypted keys" approach, right? IIUC, you're
> saying that we'll simply SHA1 the user-provided password plaintext master
> passphrase for the purpose of not holding that passphrase in memory. It's
> sha1(MP), then, that is the secret in our encryption/decryption steps.
>
> I'm not quite sure how this helps with the situation Brane has raised --
> we'll still be holding the actual encryption secret in memory, it just now
> looks less like a human-readable passphrase. But maybe that's the
critical
> difference?

Correct. Still useful, but even if memory is compromised, the SHA1 is not
reversible. The original MP cannot be recovered for other uses.

Cheers,
-g
Received on 2012-04-06 16:48:30 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.