patwolf

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by patwolf

  1. This is misleading and its untrue that it was accepted from user side. A lot of this discussion was how insecure the "secret" is and that new peers needs to be explicilty approved (like SyncThing does). BitSync always maintained no worries the secret is hard to guess and then BitSync pretended that approval was added so people are safe now. The reality is that the approval was only a surface gimmic while underneath anybody with the key had full access. With proper approval it doesn't matter if anybody obtains or guesses the key it's just a folder identifier. It's good that it has been improved in 2.0 but it was badly handled upto 1.4 and the authorization gave users a false sense of security.
  2. Roman the link requires approval but the secret does not. So if the secret leaks the folder is vulnerable with BitTorrent Sync. To prove my point (just tested in 1.4): - create a folder in the desktop app - share it and select approval required - share it via QR Code with your phone (using Google Googles you can verify that the QR contains the full secret key btsync://A43YJYOLBQZF2KG44Ixxxxxxxxxxxxxxxxx?n=nexus5.download.family) - add the folder on your phone. The folder will start syncing without any warning or approval notice in the desktop app. So if the secret leaks the folder is vulnerable with BitTorrent Sync which it is not the case with Syncthing.
  3. I can't see much benefit in the new "link" approval system in terms of security. If anybody is able to harvest my key by any means they still have access to ALL my data without restrictions. The approval has to happen when the peer first tries to access the sync folder with the master key regardless of how the key was obtained. For example: - the more people write tools around the BTSync API the more we'll have to provide our keys which makes them easy to harvest and without any access control the data is vulnerable. - on some NAS devices they are unofficial distributions of BTSync. How easy would it be to keep track of all the master keys users enter and then access their data? - I'm sure there are plenty of other ways to get keys Here a couple more discussion regarding the topic: http://forum.bittorrent.com/topic/29701-better-control-over-peer-devices-approve-new-and-display-history/ http://forum.bittorrent.com/topic/30679-now-implemented-interactive-pairing/ Once this is fixed I'd love to really embrace BTSync. Thanks, Patrick
  4. Would be very interested for comment from BTS staff on this!
  5. 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
  6. Totally agreed Chris. Not having proper approval for when a peer is added to a network is the single biggest drawback of BTSync and the new "link approval" doesn't solve it. The more people write tools around the BTSync API the more we'll have to provide our keys which makes them easy to harvest and without any access control the data is vulnerable. ie on some NAS devices they are unofficial compiles for BTSync. How super easy would it be to keep track of all the master keys users enter and then access their data. So again I agree that your points are needed +1 This topic has some good implementation ideas for points 2,3,4 http://forum.bittorrent.com/topic/30679-now-implemented-interactive-pairing/