Sharing Keys And Access Confirmation

[Smithers]

Hi all,

 

BTSync allows you to share keys, which is great, but it would make more sense to have an additional confirmation when someone adds your key to their BTSync client.

 

For example, I create a folder and share it. I share the key to 2 other people whom then add the key to their client, and It's at this point my BTSync client should confirm that someone wants to connect to the share.

 

The reason I suggest this is, say the shared key gets into the wrong hands. All they have to do it add the key to their client and my files will sync with them without my knowledge, but if there was a confirmation I could either grant or deny them the access. Obviously this option should be configurable.

 

I know I can lock down shares to IP address but I may not have access to those or that may be dynamic for the people I want to share with.

 

Am I missing something here as this seems like a security issue, no?

 

Cheers

S

Edited April 17, 2014 by Smithers

[piotrnik]

You can check via devices tab which computers are connected to your shares, but yes, I also would appreciate an option like this. 

[Smithers]

You can check via devices tab which computers are connected to your shares, but yes, I also would appreciate an option like this. 

 Absolutely, but firstly, I'm sadly not always at my computer so during those times it could happen, and secondly, even if I was on my machine the need to constantly check who's connected doesn't sound very efficient.

[dms2013]

Someone could as easily pretend to be one of the accepted machines?

[Smithers]

Someone could as easily pretend to be one of the accepted machines?

Agreed but then how does one protect their files from anonymous access. Another possible method is the R or R/W keys are disabled completely and only the one time keys are useable. Just thinking out aloud really. There has to be a way (configurable) to disallow anonymous connectivity or aleat confirm that connectivity.

[RomanZ]

Guys,

 

Additional device authentication immediately brings another issue. Every new device added will need to be authenticated for the rest of the swarm - which means either bunch of authentication requests OR that the swarm will need some sort of a shared storage where authorized devices might access (we'd like to avoid any centralized storage).

 

Also - think about the device itself. How are you going to distinguish one device from another reliably?

[piotrnik]

Even one-time keys would not accomplish what you are suggesting - after adding the folder on another device, that device can see the full r/o or r/w keys in the folder properties and share them further. I believe one-time keys are merely security in sending the key to another, so that you don't have to worry about it being intercepted and used later (ie it's only valid to retrieve the actual r/o or r/w key once; it doesn't prevent the user who adds the folder using the one-time code from seeing the actual secrets afterwards). 

 

I would like an option to approve new people accessing the folder, but like RomanZ said, it would be hard to do (even aside from concerns of where the permissions are stored) - perhaps everyone would have to approve a new access or everyone with r/w access would have to approve a new access (which would bring up the question of what if everyone doesn't approve it; is there a certain quorum or majority that would need to approve the add?).

Alternately, there could be some way to designate an "owner" in addition to r/w or r/o accesses (which would bring the questions of what happens if they don't respond, how many there could be, or if something happens to their setup - how they would recover it and not have to start again).

[CrayTo5]

This is an important problem, and an effective solution would significantly enhance BTSync security. The issue isn't entirely technical, nor is is limited to BTSync. It's a Social Engineering issue. Basically, if I share a secret with a "trusted" friend, and he/she betrays that trust by sharing the secret with others, the "Genie is out of the bottle" - forever. 

 

One idea that comes to mind to mitigate:

 

BTSync keys currently have a prefix that differentiates RW, RO, and E-RO secrets. Would it be possible to add another field that defines how many nodes can share the key? Let's say the person who originates the network intends the key to be used on precisely 10 nodes, and set this key parameter before distributing keys. Theoretically, an uninvited 11th node would fail to connect - (assuming that the undesired 11th node was the last device to join the network). 

 

I can already think of faults with this kludgy idea, but perhaps others have better ideas to tackle this.

[Smithers]

@piotrnik, good point, I did not realise it did this. That's a big spanner then.

 

CrayTo5 described the point far moreeloquently than I did, thanks!

 

I guess on your suggestion CrayTo5, it would still be open to anonymous access which is something we're trying to avoid.

 

Apologies, excuse my ignorance. Just thinking out aloud again, hoping to drop a few ideas for the Dev's to think about.

 

I had another idea, which might not be possible as I don't understand completely the communications behind BitTorrent. Say each client generated a complete unique ID upon install, which hashes something unique on the hardware (say MAC?), this ID wouldn't change unlike a dynamic IP address. Then it's with this ID, that is transmitted with the initial connection, you could permit or deny who has access, much like you do with the IP ACL. 

 

I hope that makes sense!