[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 04:22:39 -0400

On Apr 6, 2012 3:58 AM, "Branko Čibej" <brane_at_apache.org> wrote:
>
> On 06.04.2012 09:51, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200:
> >> This makes me wonder if we couldn't perhaps keep the whole thing as an
> >> in-memory-not-disk-backed SQLite database, then encrypt and dump the
> >> whole SQLite memory snapshot to disk. The real trouble with that
> >> approach is that debugging the database using the SQLite command-line
> >> tools would be impossible, everything would have to happen through the
> >> SVN API.
> > Presumably we'd write a tools/dev/ helper that decrypts the memory
> > snapshot and dumps it to an on-disk SQLite db?
>
> This really has other problems, too. Actually, /any/ passphrase-based
> system we use has it: "in-memory" does not, by itself, imply that the
> unencrypted data never end up on disk. At the very least, the
> unencrypted bits need to be stored in locked, access-protected memory,
> so that they don't get swapped out and can't be accessed by (non-root)
> users.
>
> OS-provided password storage systems typically already account for this.
> And, whilst Subversion doesn't take these precautions with individual
> passwords, a passphrase that protects a number of different credentials
> needs more attention to preventing plaintext leaks.

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

Cheers,
-g
Received on 2012-04-06 10:23:13 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.