From: James Curran <James@NovelTheory.com> - 2002-05-25 17:16:13
This was posted, in a slightly different form, on the SourceForce
PasswordSafe Forum, in response to another message.
Presently I "synchronize" it (using the term loosely) between my home
and work PCs, by copying the .DAT file via my PocketPC (using
ActiveSync). This uses merely the single file date for synchronization.
This is a just barely workable solution. (If I add one entry at work,
then later a different one at home between syncs, the home file ends up
overwriting the work file, losing that update.
So, I agree that we need a modified date field for each item (TODO #27),
but that's not far enough.
What I'd really like to be able to do is to create a ActiveSync module
for PasswordSafe, which can handle syncing on an entry level, not just
on the file level (And I assume a similar facility is possible for Palm
and other systems that can be synced). An important part is that the
syncing tool should be able to work *without* knowing the file password
To accomplish that, we'd need each entry to have both a last modified
date, and a (permanent) GUID-like unique identifier. These must be in
clear text, and each entry (encrypted & clear text portions) must be a
fixed size. This, along with a "last synced" date, would allow a full
automatic two-way sync for adds, deletes, and modify (detecting items
modified independently on both side between sync).
More importantly, each entry would have to be individually encoded
(instead of have the entire file encrypted at once, which I assume is
the way it's done now). This lead to very short runs of encrypted text,
which I think makes it easier to crack (though I'm not sure on this
point), which could be a problem.
Actually, the entries needed completely fixed length ---the cleartext
portion (which would actually be fairly opaque binary data) needs to be
fixed long, and include a offset and length of the variable length
encrypted entry. Further, now that I've looked at the code, it seems
that each entry IS being encode individually.
The alternative would be have the syncing tool decrypt the file before
it goes to work (and then recrypt it later). That would require the user
either manually entering his password whenever he synced (A major pain
-- I sync my PocketPc at least twice a day, once at home & once at the
office), -OR- the sync tool would need to store the password locally,
which would be a security leak by itself.