--- "Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: > On Wed, Oct 24, 2007 at 11:46:17AM -0700, Martin > Fick wrote: ... > > So, for each combination of password that can > > be used to log into the site a separate key file > > would exist. This key file would contain all the > > page-keys to all the pages that this particular > > password can access. > > This approach still suffers from the problem that if > the key files are lost or corrupted (or the passwords > needed to decrypt the key files), then all of the > page data is truly lost.
Well, sure, but one could just as easily say that if the page files themselves are lost/corrupted the data is also lost/corrupted! :) I am not sure how this scheme really provides any further risk? Maybe simply that the key files are not "bound" to the pages themselves? As for lost passwords, this scheme at least provides the ability of multiple passwords including an admin password for each page. > Also, I'm not quite sure how one would deal with > admin passwords -- it would seem that the key file > corresponding to an admin password would need to contain > the page keys for every page on the system. Yes, it would, this would not be a big deal if the page keys do not change (although I added some more thoughts to the PITS about this: see security improvements), since the admin key file would simply need a new page-key appended to it every time that a new page is created (so would any other key files which need access to the new page.) > If an admin then wanted to change the admin > password, a completely new key file would > need to be generated that would contain all > of the page keys, yes? Where would we get > that list from? A new key file would not need to be generated, but rather the private key for the admin key file would simply need to be re-encrypted with the new admin password (unless you are using the improved security method I added to the PITS.) > > [...] > > Finally, the private key for a key file could be > > encrypted in the key file with a password allowing > > the private key to be something obtuse generated > > along with the public key, but the password can be > > something simpler for users to remember/type. > Who are the "users" in this last sentence -- do you > mean "visitors to a site" or the "site > administrator"? Both, anyone one with a password allowing them access to encrypted pages. > Here's a scenario: let's suppose that I'm an author > (not admin) that wants to set a new edit password on > a page. Where does the system go to get the > (existing) page key for the page, so that > it can create the key file? Hmmm, are you really asking about the edit password? I would assume that having an edit password would not imply encryption, but that having a read password would. I will answer the question from the perspective of a new read password, let me know if that doesn't make sense? There are probably two cases here, (1) a page which never has been encrypted and (2) a page that currently is. 1) Since someone is trying to encrypt it for the first time the system would generate a random symmetric page-key for the page and encrypt the page with it. At this point there may be several key files which need to get this page-key added to them How to determine which ones? I'll admit that I am a bit fuzzy on that since I am not familiar with all of the authentication schemes available to pmwiki. It all depends on the mapping of a password to a key file. In a typical authentication scheme, one password/user (not pmwiki's default scheme,) there would be one key file per user and thus per password. But with pmwiki's default (if I understand it), since pages get passwords and not users, you would instead probably have one key file for the admin and one for each page (and thus still one key file per password.) In essence the page would act as a user/role and its role only allows access to itself. 2) Instead of creating a new page-key, the current page-key will just need to be re-encrypted in the current author's (or page's) key file. > (Regardless, the above scenario sounds _far_ more > complex than anything I want to implement anytime > soon, so I highly recommend that a cookbook recipe > be made for it if someone is truly interested.) Whole heartedly agreed!!! I was assuming a recipe and would probably be willing to help someone implement it, -Martin __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
