Security

[linux only]

I read through this thread. I work in an office, where I manage the server - untrained, but methodical/logical and hire in IT help for stuff I don't know, common in small business. So I use my 'lay person' understanding to reference to security. Right now bitsync uses a one piece authentication, just the "secret". It would not be much to add another layer. This could be a username/password combination, plus the secret or something else. Or perhaps even the correct name for the folder being synced.

Consider: you want access to the server at my office, you must enter a username, password, and then you must enter a randomly generated numerical key. Seems pretty simple to me to add a simple additional layer. Certainly if BitTorrent wanted to sell us a corporate version, we'd probably consider this as essential. I have no idea of their business model, but wonder about a distributed little private net of data having the eventual potential to challenge the traditional server model if the security has the right optics. And by optics I mean, is easily understandable as meeting the perceived security needs. I get the mathematical arguments about the 'secret' as it stands, but it doesn't meet the illogical perception of a group of partners in a company, who want security and also want to feel secure. Just sayin'

[qcbqoucq]

i'd be happy if it stays as it is - simple.

[ckesselmeier]

@linux only

I see that authenticating a user and by that connecting changes to an identity is desirable in a corporate environment.

But I don't see an effective way of implementation for a non-hierarchical network of btsync-nodes without introducing an external authority eg. a CA or a distributed database per share in which an existing node could vouch for the identity of a newly added node.

If it comes to authorization (is the user allowed to r/o r/w access the share?) I'm not sure which additional layer of security a user / password combination would give, except from it being a longer secret effectively.

[linux only]

I don't know that connecting the changes to an identity is needed, just the assurance that authorized people are accessing the synced/shared files. And again, please understand that it is perception, not fact that drives such things. In a corporate environment where things like privacy legislation and tangible assets (money) is involved, it is a non-starter to say "this one thing is rock solid" even if it is. It has to look the part as well as being it.

I'd rather have the things that withstand a professional corp audit on first glance than have to explain in detail how it works and why it's so fine, saving on the hearing and legal representation.

I realize I'm coming to this from a different perspective, and probably should bow out, as I don't want to totally redirect the thread to considering how to deploy this in my peculiar environment. If the BitTorrent folks read the forums, they will have noted concerns like mine. Thanks for the discussion.

[yottabit]

The random secret being used now is adequately strong and unique, and generally far more secure that username/password combinations. Don't think of a username & password as two separate things... they aren't. It's just a single secret, no different than BTSync is using. User:Password v. ABC234..., etc.

Unless you have extraordinarily long and random usernames & passwords, they are less secure than the secrets being generated by BTSync.

Now two-factor authentication might have some uses, but would also complicate things. And like has been posted before, once your data is shared, anyone can share it with anyone else (on the same secret or on a different secret). BTSync doesn't use DRM and it shouldn't.

[gpops]

Can anyone suggest a good program that generates strong keys locally?

I'm looking around for pre-built AHK scripts... might play around with:

http://www.autohotkey.com/board/topic/84783-functionrandom-string-generator/

[ckesselmeier]

@linux only

As yottabit and I write there is no difference between a username:password and a secret from the "something you know" perspective. Except from username:password alone being shorter and thus less secure.

The issuer can't be sure that you don't give it away, same goes for giving away the secret, so access is transitive.

Nothing can be done to improve the perceived security here, I'm afraid.

However username:password or any way of identification of the nodes without a doubt (signatures) would mean accountability for changes to data. Auditors like this.

[PeterVerhees]

Can anyone suggest a good program that generates strong keys locally?

I'm looking around for pre-built AHK scripts... might play around with:

http://www.autohotke...ring-generator/

This script only uses specific characters, hugely diminishing the entropy of your generated key.

Use something like this (on Linux), sorry no Windows experience here...

Change the 42 after the -c for lengthier keys.

head -c 42 /dev/random | base64 -w 0

[qcbqoucq]

i'm affraid BTsync accepts only alfanumerical characters.

[gurkesaft]

1) Add a "Lock / Open" facility. When users are happy with a client network setup any connected client user should be able to click a "Lock / Open" button to lock the network. When locked, BTSync should not permit any more clients on that share (i.e. simply ignore any new IP requests to sync). Clicking the button again will allow new clients to connect to the shared folder. To do this, each new BTSync client will probably need some sort of local folder specific GUID - with all other known connected clients being listed on a shared GUID list. Only listed GUIDs would be synced with.

I am also 100% for this idea! Or a similar idea:

3) Have a notification when a new device is trying to connect, that requires approval from one of the existing devices.

Even if "denying a new device" requires that the key be randomized and re-entered on all the devices (as I suspect it would for security reasons), this would eliminate the threat of a stolen key (as well as prompting users to think about how to avoid losing keys).

In terms of user interface, this could be a "manual approval of new members" checkbox that is by default unchecked.

[btusername]

please keep in mind that your keys, no matter how they are generated, how long they are, or how random, are not secure in any way if you send them via insecure methods like

unencrypted email

chat

facebook, aol, yahoo

this includes all communications that are "secured" with SSL unless they are using DHE or some form of PFS (perfect forward secrecy).

This is because, the ssl keys are being handed over due to gag orders and wire taps required by the NSA and government.

This is also thought to not be only obtainable by the NSA due to speculation that is off topic. But in short, your keys and data are only as secure as your weakest link, and that would be at this point sharing the keys to sync, the storing of those keys, etc.

Some one earlier mentioned using GPG/PGP to encrypt the keys I believe. I would ask, if your going to take the time and effort to encrypt the keys, why not just encrypt whatever it is your sharing, and sync it with other methods.

[fa2k]

Here's what I do to generate a much longer Secret:

I generate a secret, copy it, generate another, paste to add previous to end of new secret, copy it, generate another, repeat until it's really long

Make sure to clear the clipboard afterward

[ChrisH]

That's what the one-time-secrets are for.

[amartins]

Has anyone else installed BTSync on their server?

The web gui doesn't use SSL. Is there a way to accomplish this? Are my folder secrets being transferred via plain text (http)?

[Disappointed Cat]

It does support SSL. You can specify the https protocol in the URL. However setting up your own certificate can be tricky so instead I recommend using a reverse proxy which comes with additional benefits. Here's a topic for apace reverse proxy.

This way you get to set up your own authetication, SSL ciphers, and be sure that the web server supports DHE+ECDHE.

[gpops]

NSA defeats many encryption efforts

The encryption is no longer safe... who knows if there are methods developed to crack encryption, or if they're just using supercomputers.

http://www.cso.com.a...yption_efforts/