On Fri, 2006-02-10 at 22:46 +1100, Tony and Robyn Lewis wrote:
> Erik Grinaker wrote:
> > On Fri, 2006-02-10 at 09:27 +1100, Tony and Robyn Lewis wrote:
> > > 1. My main concern with something like Revelation (other than strength
> > > of cryptography of the encrypted file) is having *all* your passwords,
> > > in the clear, in memory, when you've unlocked Revelation. One solution
> > > would be to have more than one Revelation and password file, but I
> > > wonder if it's more elegant, and simple enough to do, to have an
> > > optional separate layer of encryption on selected folders, so you can
> > > put, say, your banking passwords in there. It might even have a
> > > separate timeout before it locks and purges memory.
> > >
> > Hm, this issue is a tricky one. The solution you outline probably isn't
> > the way to go, because the whole point of Revelation is to have a secure
> > place to store all your passwords. If we have two levels of security in
> > Revelation, then why don't we just as well use the highest level of
> > security all the time?
> No, I was thinking of using the highest level of security, but that a
> given folder could be encrypted with another password - either in lieu
> of the original password, or as well as.
> The increase in security comes from the fact that your super-secure
> passwords are unencrypted in memory for *less time* than your bulk
> passwords - not that they were encrypted with stronger security.
> You could achieve the same thing with two Revelation files, and just
> opening the one you want, but that seems inelegant.
Yeah, I know what you're saying - but for the "average user" (if there
is such a thing) it might appear as if there are two levels of security
if I include an option to "secure" a folder or something. "Isn't
Revelation supposed to have secured my passwords already?"
I agree that it's a major problem that passwords are stored in memory in
plaintext, and it's a problem I'm very interested in finding a solution
to. But I think we should try to solve this in a way that is largely
hidden from the user.
Your proposal, while it would help keep passwords out of memory, is more
of a workaround than an actual solution. And I think it would make
things more complicated both for me as a developer (undo/redo handling
will be a nightmare, just to pick an example) and for the user
(confusing options, non-searchable accounts, etc). I'm also a bit
worried that features like this will need quite a bit of UI-modification
to be easy and hassle-free to use, while probably only a small part of
users will actually use it.
So I actually think that using multiple data files, as you're doing now,
is both simpler and more elegant than adding lots of cruft (code-wise
and UI-wise) to basically achieve the same effect. But we could perhaps
try to make it easier to work with multiple data files. One possibility
would be to add a recent documents menu for quickly loading files.
Someone also suggested making it possible to have multiple files open at
the same time, using a multiroot approach - and while I believe this to
be overkill, it's worth considering.
Anyway, I'll give some more thought to the whole memory issue - maybe
I'll find a better way to handle it.
Erik Grinaker <[EMAIL PROTECTED]>
"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
-- Albert Einstein