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

[Daniel Shahaf <da...@elego.de>]

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?

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

[Greg Hudson <gh...@MIT.EDU>]

On 04/06/2012 10:47 AM, Greg Stein wrote:
> Correct. Still useful, but even if memory is compromised, the SHA1 is
> not reversible. The original MP cannot be recovered for other uses.

Just as a reminder, SHA-1 is not recommended for use in new applications
at this time (http://csrc.nist.gov/groups/ST/hash/policy.html).

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

[Greg Stein <gs...@gmail.com>]

On Apr 6, 2012 10:36 AM, "C. Michael Pilato" <cm...@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

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

["C. Michael Pilato" <cm...@collab.net>]

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?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

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

[Greg Stein <gs...@gmail.com>]

On Apr 6, 2012 3:58 AM, "Branko Čibej" <br...@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

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

[Branko Čibej <br...@apache.org>]

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.

-- Brane