Korkman Posted July 20, 2014 Report Share Posted July 20, 2014 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 Quote Link to comment Share on other sites More sharing options...
ChrisH Posted July 21, 2014 Report Share Posted July 21, 2014 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. Quote Link to comment Share on other sites More sharing options...
Korkman Posted July 23, 2014 Author Report Share Posted July 23, 2014 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 exampleHomePC:MobilePhone:Allow:TimestampStranger: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. Quote Link to comment Share on other sites More sharing options...
ChrisH Posted July 24, 2014 Report Share Posted July 24, 2014 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? Quote Link to comment Share on other sites More sharing options...
Korkman Posted July 24, 2014 Author Report Share Posted July 24, 2014 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. Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted August 26, 2014 Report Share Posted August 26, 2014 @all, the ability to manually "approve" peers/devices is now present in Sync 1.4 Quote Link to comment Share on other sites More sharing options...
patwolf Posted December 7, 2014 Report Share Posted December 7, 2014 @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#entry89214PS: +1 for the .syncDevices idea Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.