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]> http://erikg.codepoet.no/ "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 enthusiastic about." -- Albert Einstein
