[Now Implemented!] Interactive Pairing

[Korkman]

The current process of adding devices to a share is kept simple and fast. Copy the key, paste, the device has access to the share. The major drawback here is that the key, should it fall into wrong hands, immediately allows an attacker full access to the share. For example when the mobile phone QR code is presented on screen, a camera across the room could easily catch that.

 

I propose a list of known devices shared within the folder. When a new device appears, a dialogue would appear on all currently active devices asking for permission to add the new device. A "yes" would add the device to the local list, which then will be distributed to all devices.

 

This should be a per-share option for the user to activate. Also, it should be possible to remove a device from the list. Just editing the file in a text-editor would be fine.

 

Thanks for your attention and this great product which makes life alot easier,

 

Korkman

[ChrisH]

So what happens if the user on one device clicks "yes" and another clicks "no"?

 

As I have said many times now, the problem with requests like that is that BTSync's design treats all R/W nodes as equal. There is no master node that could control things like device access, secret renewal etc.

This needs to be solved first before any ideas about a node approval process can be considered.

[Korkman]

Basically the same that happens when a file is edited in two places: "User action wins", so the later decision will overwrite the earlier.

 

As soon as the client recognizes a change to the list of valid devices, the event could close any "Yes" / "No" dialogs and in addition show a notification "device X has given / denied permission to device Y to join share Z at Timestamp".

 

 

From a data perspective, all I see is a hidden file .shareDevices with lines like

 

Device:ActionDevice:AllowOrDeny:Timestamp

 

 

For example

HomePC:MobilePhone:Allow:Timestamp

Stranger:HomePC:Deny:Timestamp

 

which is shared like any other file.

 

The idea is not strict security, but to have more awareness on new devices joining a share.

 

Ultimatively, an attacker armed with the currently joined UUIDs / device names could bypass this measure easily - and I doubt there's anything that can be done about it. In fact, a cloned hard drive will always allow an attacker to join the share without being noticed (in which case he already has the data anyways). But that's physical security which is easy to handle for the user.

[ChrisH]

The idea is not strict security, but to have more awareness on new devices joining a share.

 

As long as that proviso is understood and made clear to the user: +1 from me. I also think your idea of an .syncDevices file should work.

I just would like to see something better than the easy-to-guess device name for that identification purpose, at least internally. Maybe the already existing .SyncID printed as base64?

[Korkman]

I don't know how the protocol deals with SyncIDs / device names at handshake time. Depending on when and how SyncIDs are exchanged in advance, it may be easier to generate something new like an AuthID and use that for the process. But that's left for the devs to decide

 

Upgrade transition to an "authorized" share is probably a bit difficult here. The user should be informed that devices A B C have compatible btsync versions installed and device D will disconnect when the share is upgraded until client on D is updated. There's really lots of UI stuff associated with this process but I think it's worth it.

 

Btw. when a user denies access to a device, he should be strongly encouraged to re-key.

[GreatMarko]

@all, the ability to manually "approve" peers/devices is now present in Sync 1.4

[patwolf]

@all, the ability to manually "approve" peers/devices is now present in Sync 1.4

 

It's not really present as anybody with the key has access to all the files.

The approval really needs to happen when the peer first tries to access the network with the master key.

I can't see much benefit in the new "link" approval option as it still doesn't fully secure my data (ie if anybody harvests the key)

 

Please also see:

http://forum.bittorrent.com/topic/29701-better-control-over-peer-devices-approve-new-and-display-history/

http://forum.bittorrent.com/topic/31026-now-implemented-option-to-allow-device-on-sync/?hl=approve#entry89214

PS: +1 for the .syncDevices  idea