Different view on security perspective

Hello!

I love how Syncthing cares about security. But it is not very user friendly.

I have a suggestion. Why not move all “devices” to advanced settings and make initial share easier, allowing share folder without forcing user to setup devices first.

How it gonna look?

I add unique folder id, with it’s name. Share it using QR code with any device and it starts syncing.

After I open folder advanced tab, I can see connected devices and make then permanent by clicking on checkboxes, listed in device tabs with its names, and restrict folder to sync only with specified devices. Like syncthing currently does.

That will make setup way easier for end user. At first, he have only to share folder id, and then do everything from web interface.

Security does not suffer with this logic, but end user will be more happy. You not going to force him add devices at first step.

For the security to be equivalent, this needs to be roughly as long and annoying as the current device ID is, though?

I think this does need to be made easier. But I think finding a smart way to authenticate once without long ID numbers would be better. Things like time limited one time PIN codes, etc.

I see, long folder id can be an issue. But as well a solution.

Current setup very annoying and not user friendly. Especially for mobile version of application.

Now I’m talking only about initial setup made easier. So. Long folder id + advanced tab where you can lock folder instantly == good security + user friendly.

One step in this direction would be a QR code that contains both device ID and folder ID, and sets both of them up automatically. I think we discussed that previously, but didn’t implement it anywhere.

QR codes are just a complement, not a solution. We already have a QR code, and it only helps when you have QR code reading kind of devices in physical proximity.

So this whole one time pin thing works well, apart from the fact that we have to move the authentication layer up.

Right, the QR code would of course represent a string, something like DEVICE-ID;folderid. Or maybe even Json data.

For the one time PIN mechanism I envisioned something like this, requiring support from the discovery servers.

  • “Sender” requests a “short device ID” from the discovery servers. These are valid for 24 hours, look like “aHyV5” or possibly “cake table orange love blue” depending on what encoding scheme we like.
  • Sender adds a temporary device in the config, generates a one time PIN code like “8539” for it, and adds it to the relevant folders.
  • Sender tells “recipient” the short code and the PIN. The both were displayed automatically when they created the temporary device entry.
  • Recipient enters the short code and the PIN in an “add connection” dialog.
  • Stuff connects, authenticates using the PIN code (which is then consumed), and the devices are added on both sides. The folders get added on the recipient side at this stage, using our current dialog or something superior.

This reduces the flow to one side generating a “share” with a reasonably human readable code + PIN, and the other side entering those two things somewhere.

Throwing another option out there: a custom url scheme. Generate a url with the scheme syncthing:// which when clicked launches the browser showing the web gui with the appropriate boxes pre-populated.

Would probably work best with one-time keys and a means for both devices to be added to both ends at the same time when the link is clicked, but is slightly more streamlined for the users (no copying and pasting codes) and means we don’t have to worry so much about keeping things short and memorable.

1 Like

How would that work with different discovery servers? Sounds like the “sender” would have to request this short ID from every discovery server seperately. Then you have problems if a device isn’t connected to all discovery servers.

Maybe discovery servers could exchange the short IDs between them?

Ok how’s this for a use-case: user A clicks “share this folder”. Syncthing combines its device id, the folder id, and possibly the current time and a nonce, to create a clickable link. Syncthing will probably need to record this to prevent reuse later. User A sends this to user B. User B clicks the link, and syncthing shows a prompt asking for the folder path and options. Device B adds device A (if it isn’t already added) and initiates a connection, providing some details (folder id + nonce?) contained on the link. Provided those details are correct (not too old, match a nonce given out previously, haven’t been used before, etc) device A accepts. The same procedure is followed for the folders.

Sure, but only usable when you are anyway able to just copy & paste. I’m guessing the most annoying setup hurdle is when you don’t have that ability for whatever reason.

That would be required, yeah.

Absolutely doable, but again requires that the two boxes are already in electronic contact with each other. We should that case for sure, but it’s the “setup over telephone” case that’s really painful today.

I can suggest you this idea:

We need create centralized register service. Like bootstrap IP works for DHT.

Under this register (you can run your own, or use syncthing one) you declare namespace under which your syncthing operate and share all devices id and folders id.

For example I declare I live under google.com. And I wish to share my folder ‘123’ with you. Another person by phone ask me about folder details and my host name I Say: “goolge.com photos333”. Person, tell me his namespace, yahoo.com and pool.

This namespaces can be optional tags for your current servers and can be registred, unregistred or reregistred.

Few more words about current setup with devices && folder names.

If you have few devices (4): desktop computer, notebook, smartphone, tablet. Adding/updating devices, adding folder one by one (for example if you have 2 or more), using all setup dialogs, settings - makes first setup and further updates very complicated and can take 10 or more minutes (including setup for smartphones).

I vote for global folder guid + optional security by filtering peers from your folder after connection initiaed.

It can be done even simpler. If we have centralized ‘shake’ service, one person call another by phone and click share button on folder. 5 digits appears. Another person click ‘add folder’ and enter those 5 digits.

Central server keep only active requests, 5 digits enough to keep 99999 requests at the same time. And for requests share all necessary information.

To keep this way of communication secure, it is necessary to show more information about folder and peers connected. I think visual control using global GUID for folder and peers would be ok.

Actually I like this idea, I am just a bit worried about the ability to brute force/hi-jack by performing man in the middle during the acceptance period. Also, malicious shake server can get access to anyones data by using the token itself.

@AudriusButkevicius you gonna see all hack attempts because you see GUID’s and your app dialog warn you about what you have to focus on (GUID’s of course). Only bad things can happen - you action to find your friend will be temporarily blocked by some hackers, if they try to push you wrong GUID’s. And they have to do a lot of job to catch all users folders and mirror them, to have success direct attack on specified person.

Shake server only helps people find each other it has no keys. My conclusion not possible to do MITM.

And this Shake server - open source, and be run on any machine. You can run your own.

That makes devices second priority, and Syncthing users can focus on data they are syncing (folders), not devices.

Sorry, I am not sure I follow you. Are you suggesting we replace the device id with N digits for the initial peering setup, but you still need to confirm the device as it connects to you?

Also, there is no GUID’s involved, so I am not sure what you mean by GUIDs.

(Also remember that GUIDs are not cryptographically secure - do not use a GUID where you want something that can’t be guessed).

By GUID I mean global unique identification key, which can be used as public key. I believe current implementation of device id follows this description.

I suggest change view perspective. Currently I have to work with devices, which holds data. Which makes full process complicated and restricted for end user (for example I unable make internet shared folders with this logic). I want to work with data which identified by global ID.

I like the initial idea presented, but am strongly against any kind of centrally trusted entity, which the “shake server” idea @axet described seems to be. I have to say that I haven’t fully understood how they are supposed to work either, because any entity which removes the manual acceptance/check on each device is automatically a trusted third party entity.

If it only makes finding the other devices easier, it sounds like a worse version of the temporary ids on the discovery servers.

1 Like