Chain of trust

[drax]

I think this could be a major security flaw.

If I share a Read/Write secret with someone, there's nothing to stop them passing that on is there ?

I mean I have sight of who's using my shares in the Devices tab (I'm using the Windows client) but I have no control over them, I can't kick/ban them, throttle them or downgrade them to read-only.

I think this is gonna be difficult to implement but I think it's gonna be a must-have. You need a "ripple effect" to your shares, so people can't reshare. I'd only want to grant read-write access to a certain group of people, and maybe read-only access to a larger group, I wouldn't want any of them to pass that access on. Basically we need to be able to control the ability to limit reshares or deny them altogether.

[drax]

Okay another brain fart on this subject.

The problem is that the shares are pushed out to peers in plain text.

Maybe the share mechanism should go something like this :-

I create a share on my local drive and generate a secret as we do now.

I then distribute that secret to the people I want to.

They setup their local folder and paste the secret as they do now.

Their client now sends a *request* to my client, which I can then manually approve or deny.

Assuming approval, my client sends an encrypted secret to their client, this secret is unique to this particular peer bonding.

The secret is only decrypted by their client when it requests access to that share. My client, being the client of origin, would need some way of ensuring that this particular encrypted secret is only used once.

That's actually a lot more clunky than I initially thought it'd be. Ideas ?

[sc13175]

I totally vote for this idea to be implemented. It should be possible to deny sharers from re-sharing a folder freely. There should be some control to you as the creator of this share. Otherwise you never know who all is looking at your share.

[dokument]

Perhaps adding "single license" secrets? Keep the current ones but label them as group secrets. I dislike the request idea only because it could be use maliciously so easily. I personally think that the user handling the management of the secret is much better. If you had to send a secret to someone that you were not physically near and you don't trust email/texting/phone then there is always bitmessage. Incorporating a new system to send encrypted secrets seems not worth the effort (compared to the risk being taken).

I am fairly new to bittorrent sync and not 100% familiar with the inner working yet so excuse me if something I have said is ignorant.

[kos13]

I think this could be a major security flaw.

If I share a Read/Write secret with someone, there's nothing to stop them passing that on is there ?

I mean I have sight of who's using my shares in the Devices tab (I'm using the Windows client) but I have no control over them, I can't kick/ban them, throttle them or downgrade them to read-only.

Read only is the first step in this direction and I do agree this feature needs more work. We plan to add more granular user management to Sync.

[cakruege]

It's impossible to disallow reshare, I think.

If you give an encryption key away, it is away. That's normal.

It would be a nice idea to have x keys for the same folder, and make it possible to revoke one.

[GreatMarko]

Perhaps adding "single license" secrets?

Isn't this the same as the "one-time secret" option that already exists in BitTorrent Sync?

[drax]

Isn't this the same as the "one-time secret" option that already exists in BitTorrent Sync?

I haven't used that feature yet but from RTFM my understanding is the one-time secrets are exactly that, a secret that is used only one time by one client to do a one off sync.

A single user secret, and it's a very a good idea IMO, would allow one user to sync as many times as they wanted but they'd be the only one able to use that secret.

[rdebath]

This is all about certificates style authentication.

The Certification authority signs everyone's private certificates and the peers validate each other's certificates before they make a connection. Nobody (not even the CA) gets to see anyone else's private certificates so they cannot pretend to be each other. A 'kicked user' list (normally called a certificate revocation list) can be circulated to say what signed certificates are no longer trusted, it's normally also signed by the CA so only the CA can create a valid revocation.

As every peer has a unique ID (certificate) the peers can make sure they only accept a certificate from a single IP and they can tattle to the CA if they have active connections from multiple IPs for one certificate.

Having described all that, I'm not sure I'd really want it. There will be times when I want to work in the current fashion where you can publish the read only (or even the RW if you're brave) key to all who may be interested. And frequently, all the hosts for a secret share will be under the same control so a shared secret authentication is the simplest solution and hence the best solution.

But if you're going to use certificates, or a kind of "plugin" authentication scheme, the very first thing you must do is to detach "identification" from "authentication". What this probably means, in concrete terms, is to separate the "info hash" from the "secret". eg: The "info hash" would be a hash of "Tom's private document store created 12/12/13" the secret would be "b0227da3e6105bb5546d9d0f00a9bc23" and they have no relationship to each other what so ever.

[kos13]

Having described all that, I'm not sure I'd really want it. There will be times when I want to work in the current fashion where you can publish the read only (or even the RW if you're brave) key to all who may be interested. And frequently, all the hosts for a secret share will be under the same control so a shared secret authentication is the simplest solution and hence the best solution.

Thank you for the explanation. This is exactly the way we were thinking about using private key vs certificate based authentication/authorization. There are definitely cases, where certificate based approach will win over secret/key based approach. But it will lose in other scenarios. We think that Secret approach is so basic and secure at the same time, that it could satisfy any use case, of course with some involvement from the user (you need to care to whom you give the key and what type of key).

[Seán]

Besides trust, one big potential issue would be getting malware that grabs the list of secrets, particularly with a large team of users, as the more devices there are with the same secret, the higher the chance one will get hit by malware, possibly without even the affected user knowing. Another possible way would be if the key is eavesdropped, for example, if anyone's e-mail account is compromised the hacker could do a search for any e-mail containing a BT Sync secret.

Certificate based authentication/authorisation is one way to go, but instead of using an major certificate authority, one option would be to allow one device to run as a master with a private certificate authority, like with Windows Server.

Off hand I cannot think of any other way of preventing unwanted key sharing. For example, if MAC address authentication is used, the malware would just need to read the MAC address so the hacker can spoof it. On the other hand, if MAC address, device ID, etc. authentication is used, BT Sync could throw a security warning if two different IP addresses connect with the same MAC address or identification method and cause all clients to discontinue sharing until the secret is changed.

[kos13]

Besides trust, one big potential issue would be getting malware that grabs the list of secrets, particularly with a large team of users, as the more devices there are with the same secret, the higher the chance one will get hit by malware, possibly without even the affected user knowing. Another possible way would be if the key is eavesdropped, for example, if anyone's e-mail account is compromised the hacker could do a search for any e-mail containing a BT Sync secret.

If computer is compromised, then you could do a lot of fancy things and there is no protection against of that. In case of certificate malware could steal your private key and pretend these were changes by this user, since it will be properly signed.

Certificate based authentication/authorisation is one way to go, but instead of using an major certificate authority, one option would be to allow one device to run as a master with a private certificate authority, like with Windows Server.

It won't help in any sense. As I said earlier, any compromised machine could do any change and remotely you can't tell whether it was good action or malicious.

Off hand I cannot think of any other way of preventing unwanted key sharing. For example, if MAC address authentication is used, the malware would just need to read the MAC address so the hacker can spoof it. On the other hand, if MAC address, device ID, etc. authentication is used, BT Sync could throw a security warning if two different IP addresses connect with the same MAC address or identification method and cause all clients to discontinue sharing until the secret is changed.

Maybe I just don't understand problem that you are trying to solve. But even with strict control of secrets and user management, user who got access to files could simply copy it to different share and distribute another key the way he wants. And you won't be able to control that.

[Mikuz]

Maybe I just don't understand problem that you are trying to solve. But even with strict control of secrets and user management, user who got access to files could simply copy it to different share and distribute another key the way he wants. And you won't be able to control that.

In addition to protection of information itself Sync could be good in protection of network users.

In a very strict scenario client certificate would be associated with an IP address. Changes to this pair would need to be allowed by an administrative certificate. Other clients would only synch with allowed IP address/certificate pair.

This would be pretty effective way to protect IP addresses of seeds and peers.