What options are there for synching desktops (Linux, Windows) and iOS devices?

2014-05-06
2014-05-09
  • Steve Cohen
    Steve Cohen
    2014-05-06

    The IOS device software (so far I've only looked at MiniKeePass) don't seem to allow synching with the FTP site I just set up for my Linux boxes. What storage option would work across both platforms?

     
  • wellread1
    wellread1
    2014-05-07

    Dropbox provides support for Windows, Linux and iOs. Other than that you will need to research the specific features of various KeePass ports, or find applications for the each OS that can provide access to a particular central location.

    It looks like TeamDrive supports all three OSes.

    As far as I know, none of the third party KeePass ports can perform a KeePass file synchronization (sync the database contents as opposed to replicate the entire file).

     
    Last edit: wellread1 2014-05-07
  • Paul
    Paul
    2014-05-07

    As long as you can open and save to a remote site you can use KeePass proper to do the sync.

    cheers, Paul

     
  • Steve Cohen
    Steve Cohen
    2014-05-07

    Thanks, yes, dropbox is a cross platform solution that works.

     
  • steelej
    steelej
    2014-05-07

    Many of the cloud services support FILE relpication which will ensure that all of the database files are the same. This does not eliminate the change of loss of data though if there is any chance of updates being made on two different systems before the replication process has been completed (e.g. out of mobile phone signal range). In this case the earlier update would be completely lost as the cloud replication will overwrite it.

    KeyPass version synchronisation operates between two copies of the database and compares key records which avoids this risk but, as far as I am aware, there are no phone apps that currently provide this feature. I use the file synchronisation but avoid making changes on my phone - I have made the replication operate to the phone but not the other way round. This is far from perfect but at least it is safe.

     
  • steelej
    steelej
    2014-05-08

    A further thought on synchronising KeePass databases where the ported App does not provide database sync. The suggestion below has not yet been tested - I have just been trying to think of a workaround for the current limitations.

    • Create a separate copy of the database in cloud storage for EACH phone etc. where the synchronisation by a trigger is not supported.
    • On one (or more) PCs create ensure that each of these databases is accessible via cloud replication - this must be on platform that does support triggers and synchronisation.
    • On the PC(s) create a trigger that separately synchronises EACH of these databases with the master cloud version as well as its local copy. [It may be necessary to run the synchronisation twice if there is more than one phone type device to cover all permutations]

    This would ensure that when the database replicates back to (each) phone they will ahve the correct data. It would also ensure that changes made on a phone would be propagated (but only when the PC is on and has run KeePass - synchronisation between two phone devices would not be immediate).

    If the ports to the phone devices are ever enhanced to support triggers enabling PC like synchronisation behaviour then the phone sync triggers could be removed.

     
  • Paul
    Paul
    2014-05-08

    You would need to run a sync for each database and the first database synced would not get any changes from later databases, unless you ran the sync twice on each database - actually n*2-1 syncs. The way around this would be for KeePass to perform multiple syncs in one go, i.e. select multiple databases, then sync all.

    cheers, Paul

     
  • steelej
    steelej
    2014-05-08

    I have created a drawing to illustrate the replication process. This shows two phones and a PC. There are 5 synchronisations involved. In the description the term Master PC refers to the PC (there can be more than one) which keeps all of the databases aligned.

    It is assumed that the phone updates have already replicated to the cloud and from there to a mirror copy on the master PC. Each phone will have its own database.

    • Sync 1 - Local KeyPass database to local copy of cloud database. Depending on timing this replicates to cloud copy.
    • Sync 2 - The local copy of Phone 1 database is synchronised to the local master copy of the master database which now contains local changes and PC changes. Again this may replicate to the cloud. The local copy of phone 1 database will contain changes from the PC
    • Sync 3 - As Sync 2 but using Phone 2 data. The master database now contains all updates from all devices. Phone 2 database will contain all changes
    • Sync 4 - this will ensure that phone 1 contains all changes
    • Sync 5 - this will update the local PC database. Now all devices will contain the same database entries.

    All changes will be replicated via the cloud to all devices. [Note that some cloud services delay replication so that the master database which might be updated three times should only be sent to the cloud once]

     
  • wellread1
    wellread1
    2014-05-08

    It is an interesting scheme. The scheme may reduce file conflicts under some conditions but does not eliminate them, because conflicts occur when any keepass synchronized replication copy collides with a changed phone copy at the cloud server.

    You can also completely eliminate the Yellow databases (they doen't lead anywhere) and sync directly with the Phone copies. The double syncs 2-3 & 2-4 do not eliminate file conflicts except to the extent the could be performed infrequently. The number of syncs required would be n-1 where n = number of end nodes (including keepass end nodes).

     
    Last edit: wellread1 2014-05-08
  • steelej
    steelej
    2014-05-09

    The Yellow database is there for synchronising to other PCs - I should have made this clear. If you are only synchronising to phone devices then it is not necessary )but does provide a backup of the local database in the cloud which may be a good thing to do).

    I suggest the scheme could make a step towards eliminating the risk of data loss.

    Consider the following situation

    PC creates 1 record "Pears"

    • Local PC = [Pears]
    • Sync 1
      • Local Master Database -> File replicate
        • Cloud Master Database -> File replicate
          • Other PCs via their own triggers
    • Sync 2
      • Phone 1 PC copy -> File replicate
        • Cloud Phone 1 -> File replicate
          • Phone 1 = [Pears]
    • Sync 3
      • Phone 2 PC copy -> File replicate
        • Cloud Phone 2 -> File replicate
          • Phone 2 = [Pears]
    • Sync 4 - nothing to do
    • Sync 5 - nothing to do
    • Result
      • Local PC = [Pears]
      • Local Master = [Pears]
        • Cloud Master = [Pears]
      • Copy Phone 1 = [Pears]
        • Cloud Phone 1 = [Pears]
          • Phone 1 = [Pears]
      • Copy Phone 2 = [Pears]
        • Cloud Phone 2 = [Pears]
          • Phone 2 = [Pears]

    Phone 2 creates a record [Apples] -> File replicate

    • Phone 2 = [Pears + Apples]

      • Cloud Phone 2 -> File replicate
        • Copy Phone 2 = [Pears + Apples]
    • Sync 1 on PC will do nothing
      • Local PC = [Pears]
      • Local Master = {Pears]
      • Copy Phone 1 PC = [Pears]
      • Copy Phone 2 = [Pears + Apples]
    • Sync 2 will do nothing
      • Local PC = [Pears]
      • Local Master = {Pears]
      • Copy Phone 1 = [Pears]
      • Copy Phone 2 = [Pears + Apples]
    • Sync 3 will -> Synchronise Local Master with Copy Phone 2
      • Local PC = [Pears]
      • Local Master = [Pears + Apples] -> file replicate
        • Cloud Master = [Pears + Apples]
      • Copy Phone 1 = [Pears]
      • Copy Phone 2 = [Pears + Apples]
    • Sync 4 will -> Synchronise Local Master with Copy Phone 1
      • Local PC = [Pears]
      • Local Master = [Pears + Apples] -> file replicate
        • Cloud Master = [Pears + Apples]
      • Copy Phone 1 = [Pears + Apples]
      • Copy Phone 2 = [Pears + Apples]
    • Sync 5 will -> Synchronise Local Master with Local PC
      • Local PC = [Pears + Apples]
      • Local Master = [Pears + Apples] -> file replicate
        • Cloud Master = [Pears + Apples]
      • Copy Phone 1 = [Pears + Apples]
      • Copy Phone 2 = [Pears + Apples]

    Without Sync 4 and 5 two of the databases will not have [Apples]. Assuming that the synchronisation happens when the Local PC database is opening KeePass would have to close and reopen the local database before all records are fully synchronised. Eventually it would catch up.

    There is still some unavoidable chance of data loss on the Phone records if an update is being replicated to the phone at the same time as an update is being replicated from the phone o the PC. In this case however the version management on the cloud server should indicate a conflict (at least that is what TeamDrive does. This allows the user to select which version is correct. If the Phone version is always taken then any missing changes can be synchronised to the phone database by running the synchronisation again on the PC and any data anomalies can be recovered and I think no data would be lost.

     
  • wellread1
    wellread1
    2014-05-09

    The data 'loss' problem is on the phone side of the cloud storage not the KeePass synchronized side.

    A KeePass synchronized side will not lose data that originates on the KeePass side

    The KeePass synchronization of 'Local PC Database' <-> 'Local Master Database' guarantees that changes made to the 'Local PC Database' are never lost and that these changes will eventually be incorporated into the 'Local Master Database' even if the 'Local Master Database' becomes the conflicted file repeatedly. This is because each new KeePass synchronization restores the changed data.

    A phone database can 'lose' data that originates on the phone side through creation of conflicted copies on the phone side

    The problem is different on the phone side. If you make a change on the phone side e.g. at 'Local Phone 1 Database' that ends up conflicting with the corresponding Cloud storage database the database containing the changed data becomes a phone side conflicted file and is renamed. The data has not been actually been lost, but because the database containing it has a new name it is not seen by the phone or KeePass (unless the user looks for it in the conflicted copy). The changed data is effectively lost.

    How to recover 'lost' data

    The way to recover lost data programmatically is to create a routine that uses KeePass synchronization to recover 'lost' data contained in conflicted copies. It is not necessary to distinguish which side of the cloud storage the conflicted copies originated but only the phone side conflicted conflicted copies matter. It should be possible to create a batch file using 'KPScript.exe -c:sync' followed by a file deletion routine that programmatically merges all conflicted copies with the 'Local PC Database' and deletes the conflicted copies.

    Regarding your scheme:

    • Sync 1 = Sync 5 because it doesn't make any difference which is the active database and which is the target database. After sync 1 or 5, 'Local PC Database' = 'Local Master Database'.

    • If 'Local Master Database','Copy Phone 1 Database', and 'Copy Phone 2 Database' are collapsed into a singled database (i.e. the standard sync configuration) then Sync 5 = (Sync 5 + Sync 2 + Sync 3 + Sync 4). In other words, one sync does the work of all four syncs.

    • The scheme may reduce phone side conflicted copies that occur from collisions between 'simultaneous' changes on phone 1 & phone 2 because the changed databases only meet during a KeePass synchronization. However, since phone side conflicted copies are not completely eliminated I don't see that the increased complexity is justified.

     
    Last edit: wellread1 2014-05-09
  • wellread1
    wellread1
    2014-05-09

    It is assumed that the phone updates have already replicated to the cloud and from there to a mirror copy on the master PC. Each phone will have its own database.

    I missed the statement above. It is true that as long as one stipulates that 'phone side'->'cloud storage'->'keepass side' replication be completed successfully before executing a KeePass synchronization then phone side conflicted copies are eliminated. However, that stipulation also eliminates phone side conflicted copies in the simple synchronization scheme.

     
    Last edit: wellread1 2014-05-09