Syncronization between clients (Twik, Phashword, etc)

[mafrailea]

It would be nice to have synchronization between clients.

One way this could be performed would be using a file on an user-provided FTP server. All settings could be stored on a encrypted file inside the FTP server, and the password for that encrypted file could be hashed by Twik. :)

This way, you don't depend on cloud storage, and I think most final users will be able to find an FTP server on their own.

What do you think?

[daMihe]

Basically, a nice idea.

The problem is the portablility. I'm sure @gustavomondron wants to keep compability also to other plugins and programs. That does mean, we need a stable specification for how to transfer what where. Basic questions:

What do you want to sync exactly? How do you want to secure it? Does maybe already a standardized protocol (for encrypted sync) or something exist? Did you ask at other projects for support? (This is one of the most important thing before starting! A solution without support is no real solution) Are the requirements at every password hasher the same?

These questions maybe seem quite easy to answer, but they are not. Please get needed information, so we can discuss if and how we could realize a sync-module or so. If asking at publicly visible websites, please link the discussions.

Note i don't own the twik project, we should also wait for @gustavomondron's opinion.

[mafrailea]

Sorry for such a LATE reply. :D

What do you want to sync exactly?

Everything but the hashed passwords, obviously. That means syncing all profiles, private keys, website tags, password lenghts and password policies that the user decides to save.

How do you want to secure it?

You can store all those variables on a file (ini, json or whatever makes it easy to read) and then .zip that file with password using the master key from the user. I think it should be possible to unpack that encrypted zip file even using javascript with something like this.

Does maybe already a standardized protocol (for encrypted sync) or something exist?

Yes, maybe a better protocol for syncing exists, that's something that can be discussed. For a start, I think it should be possible to store that zip file on a FTP / Web server provided by the user and every client app should be able to read it.

Did you ask at other projects for support? (This is one of the most important thing before starting! A solution without support is no real solution)

No, sorry, I didn't, but maybe invoking @gustavomondron (like you did before) helps. :)

Are the requirements at every password hasher the same?

That's something I cannot answer, I think.

I'm pretty sure my initial idea is not the best solution for syncing, but I hope it can at least raise interest on the feature.

Best regards, Míguel

[gustavomondron]

Hello, I'm truly sorry for the very long delay. I'm resuming Twik development with the purpose to implement some features that I have been missing too.

Client synchronization is a must and, of course, this is going to be addressed. I still need to analyse this issue but I'll share some thoughts about it:

• My prefered way would be to use Android Storage Framework. However, it seems that some popular cloud storage services like Dropbox do not support it, so it may not be a good idea right now.
• I find the implementation in Keepass2Android quite useful. It supports a lot of services out of the box, such as local folder, DropBox, Google Drive, OneDrive, SFTP, FTP and WebDav. Given that it is also a GPLv3 project, I think it's worth taking a look at the code and reusing as much as possible.

[daMihe]

Hi,

i've done a quick look over Keepass' Implementation and Android SAF concept. Android SAF i think is not what you wan't unless you use Android 7 (i think its to early for setting that as minimum requirement).

Android 7's SAF introduces a virtual file system, wich would be excellent for that usecase and will surely be implemented by various web storage providers like dropbox. The concept of the Storage Access Framework in earlier versions is more like using files only one time. That could be used for a import/export functionality.

Keepass' Implementation is an abstraction for writing Files remotely, which is more useful now. A hint for those who can't find the implementation: It's located in src/java/JavaFileStorage of the source-zip (i've searched a bit). It does not implement a GUI, which is nice because it's possible to integrate it in twik seamlessly.

In both cases there is needed a import from/export into file functionality and partly also a GUI. @gustavomondron I'd like to help.

To make it short what should get synchronized:

• Profiles (name, key, default settings)
• Tags (name, special settings)

(De-)Serializing into json should not be a problem. javax.crypto.Cipher allows to encrypt without external libraries. There must be analyzed how a synchronization password can be saved securely.

[gustavomondron]

Hello,

I agree with you on your SAF analysis. Android 7 virtual files fit nicely to our needs but it's too early to go that way.

I have been using Keepass for a couple of weeks to find out the pros and cons on my daily routine. One of the things I loved was the ability to store additional data for each account, such as the username. I believe Keepass2Android approach is the way to go, but we need to think about a couple of things:

• It is necessary to specify a format to store all data. It should be extensible out of the box so it is possible to store additional data (e.g., username) when Twik supports it.
• It think we should avoid storing the encryption password (a.k.a. the synchronization password) at any cost. However, being asked for the synchronization password too frequently is frustrating too. Solving this issue may be a real challenge :-)

Of course, @murderered, I'm glad you are willing to help, I do appreciate all contributions.

[jamartinb]

Two-ways, continuous synchronization is hard to get right. I would use this as a one-way backup-restore approach. The only possible addition I'd consider, is maybe ask if you want to "Replace all profiles or just append new (possibly renamed) profiles" and, now that I think of it, maybe it's better to always append new renamed profiles like "Personal (restored), Work (restored), ..." and so on.

Using Keepass is cool but will likely complicate the synchronization between Android and Desktop. I'm not against it but I'd first consider why easier approaches don't work.

To begin with, what is what you consider the most sensitive data. As I see it: the master password and the private password. I don't want the rest of the config publicly available either but it is not as sensitive as the first two.

For the master password, I wouldn't store it anywhere. Just use it on the fly and remove it from RAM as soon as possible.

For the private password, I see the merit of keeping a backup. For that, I'd simply follow your thoughts: put it together with the rest of the config, serialize it, encrypt it with the master password (all of this in Twik --both the Android app and the Chrome extension) and store it in Google Drive. I know that Android apps can claim their own hidden Google Drive folder, that would be ideal if the Chrome extension could access that folder as well.

I think this is the minimum viable product towards having this feature and, if it is ever extended, most of the pieces can be reused for future versions.

What do you guys think?

[daMihe]

Maybe first define "the words":

• master password: The password which is used for password generation now.
• synchronization key: The key that encrypts data that's imported or exported (no matter which channel is used to transport the data).

So i agree twik should stay as stateless as possible. So never ever save the master password. But what we want to achieve with synchronization? Some possibilities (i'm sure you know some more):

• Backup
• Making sure, the right settings are used for every service on all synced twik-tools
• Keep track of all used services in profiles (if you use multiple) on multiple devices
• Just get the config sometimes from my phone into my chrome

The first and last one are from user-view and implementation-view quite similar: They are a manual process, the user hits a button and exports its configuration. At that time he can encrypt the exported file with the synchronization key dynamically created while saving the data. The synchronization key could be protected by the master password. I think this is the situation @jamartinb meant.

The second one is from the user-view the most comfortable, but from implementation view quite hard: In this case there is needed a two-way synchronization, the encryption key has to be more or less static [1]. The synchronization has to be done in background without entering the password for maximum comfort, so the synchronization key can't be protected absolutely securely by design. Also the user does not want to see deleted tags in other clients. This makes synchronization harder, as collisions can (murphy's law: will) happen.

The third situation is simpler from implementation side, but not optimal from users view. In this case you may use one- or two-way synchronization and merging only incrementally. If the user deletes a tag or renames it, a copy of the old will pop up again.

If we know how we want to synchronize, we can think about how to secure the whole thing. I'm sure there is a way to secure that whole thing without saving the master password.

[1] There are some possibilities using asymmetic encryption algorithms, but that would be really hard to implement right. It would be also a overloaded solution for this purpose. (In german there is a adage: "Mit Kanonen auf Spatzen geschossen", translated freely: fired with cannons on sparrows :) )