A thought it was secure ?

[My_Sic]

I am testing Sync app since 2 weeks. Except for some bandwith issues in local network, i was really satisfied of the software.

But something strange append tonight. I see a transfert to a anormal ip in the transfert tab : "0.0.0.0:0".

i quickly list the active connection on my OS, and i see a file transfert of my data to an American IP.

It's none of my device. And when i go to that ip, it seem to be a Chinese website hosted in USA.

Clearly not my device.

Do they have brute force all possible key ? Could we have a manual validation for new device to avoid all possible brute force ?

I will no longer execute SyncApp. Don't want my data to be stolen.

[GreatMarko]

I would be more concerned if you were seeing connections from an actual physical unknown IP address/port.

For information on 0.0.0.0:0 please see:

http://en.wikipedia....i/Default_route

I'm no expert, but I would suspect you are seeing "0.0.0.0:0" because SyncApp is unable to connect directly (i.e. across your LAN) to one or more of your other syn'dc devices, and therefore is attempting to "tunnel" either through your firewall, router, gateway, or via BitTorrent's servers (which might explain your American IP connection anomaly) in order to establish a connection to your other devices.

I therefore don't believe that in this particular instance you are being "hacked" or that your data is being stolen by a 3rd party.

That said, I know the SyncApp team are aware of users concerns here on the forum with the current length of "secrets" and how likely they would to "guess"/crack, etc.. and I'm sure they are looking at ways all the time of improving security of SyncApp, which - let's not forget - is still in an early "alpha" phase after all.

[pols1337]

I was wondering about the same thing when setting up SyncApp. I mean, theoretically, as long as anyone can guess my secret key they can sync one of their folders with my folder, right? Not only can they get my data, they can also force me to receive data too!

They should totally implement a two-step verification process like the Google Authenticator

[My_Sic]

It was a physical unkown adress : 67.215.229.106.

Does someone here from SyncApp team could say me if it's one of there server ?

The 0.0.0.0:0 was the device name listed in the transfert tab. Even if one of my device go trough a tunnel, i always see it's real name. Except for this one.

[GreatMarko]

67.215.229.106 would appear to be a server owned/operated by BitTorrent- so my previous comment about it likely being SyncApp trying to establish communication with your other devices (that it couldn't otherwise make a direct LAN connection to), would seem to hold true.

See the additional information for: http://whois.domaint.../67.215.229.106

...one of the contacts there is listed as a "Jason Whitlark" - jwhitlark@bittorrent.com

[GreatMarko]

They should totally implement a two-step verification process like the Google Authenticator

That seems a bit over the top IMO - If you think back to the very recent days of Windows Live Mesh, when you consider all you needed was someone's email address and their Live password and you'd then have full access to all their Mesh'd files, their SkyDrive, and Remote Access to their sync'd devices - no-one questioned the poor security that just a simple password provided for Mesh!

I agree that the "secrets" system for SyncApp does have some big drawbacks at present, however, I believe that if they removed the current fixed-length size limit on secrets, allowing users to enter/generate a key of much greater/any length, as well as permit symbols along with numbers and letters - this would make "secrets" extremely secure indeed - it would take the fastest super-computers centurys to crack a very long "secrets" then!

So whilst of course users want an extremely secure product that no unauthorized persons can access their data with, they also want simplicity and ease-of-use! - I think a "two-step" verification process requiring you to respond to a code via an SMS or phone call etc whenever you want to setup a new sync will put a lot of users (myself included!) off! ...not to mention people would then have to have some form of SyncApp "account", with their phone number associated with it! (and this is one of the things that currently sets SyncApp apart from competition - you don't need an "account", you don't have to associate your email address with SyncApp in the same way you do if you want to use say AeroFS and Cubby, etc)

I believe that by simply allowing variable length "Secrets", and allowing symbols in them also, this will allow users to achieve extremely secure syncs, whilst not making SyncApp any more complicated to use!

[PeterVerhees]

They should totally implement a two-step verification process like the Google Authenticator

Please no! Not another service/application depending on Google knowing what we do and when with whom and where. I LOVE the simplicity of the shared secret. (maybe certificate based sharing is a nice upgrade).

By the way, is there a way to prevent Syncapp to even connect to the bittorrent servers?

/paranoia mode ;-)

[GreatMarko]

By the way, is there a way to prevent Syncapp to even connect to the bittorrent servers?

/paranoia mode ;-)

In your "Shared Folders" tab, right-click on a folder and select "Show folder preferences". In the resulting dialog, untick the "Use relay server when required" option (and probably also "Search BitTorrent DHT network" - although, this isn't usually ticked by default anyway)

This should, I believe, prevent SyncApp from connecting to BitTorrent servers in any way (of course, you'll have to repeat the above for each of your "Shared Folders")

[PeterVerhees]

In your "Shared Folders" tab, right-click .....

Sorry, I only use Linux as my OS. ;-)

No such option in the WebUI for Linux. In the config file however I found this....

	 "use_relay_server" : false,
	 "use_dht" : true,

When using shared folders in the config file, it disables the Webinterface completely.

Thank you for the anwser though. I feel a bit of a nitwit as I dug through the config file before and completely missed it.

[Tsu]

That seems a bit over the top IMO - If you think back to the very recent days of Windows Live Mesh, when you consider all you needed was someone's email address and their Live password and you'd then have full access to all their Mesh'd files, their SkyDrive, and Remote Access to their sync'd devices - no-one questioned the poor security that just a simple password provided for Mesh!

I agree that the "secrets" system for SyncApp does have some big drawbacks at present, however, I believe that if they removed the current fixed-length size limit on secrets, allowing users to enter/generate a key of much greater/any length, as well as permit symbols along with numbers and letters - this would make "secrets" extremely secure indeed - it would take the fastest super-computers centurys to crack a very long "secrets" then!

The problem with secrets is that you can "crack" them without trying. It's perfectly possible that two users can end up with the same secret and thus see eachothers files. Ofcourse the chances are slim, but they do exist. Rather than creating stronger secrets where the collision chances are reduced I would like to see a system where there are two secrets and you need them both to access files. The first secret is generated by Bittorrent and is checked against a database to make sure it's unique. The other is user generated and doesn't need to be unique. Same as a username and password except the username is just a random string.

[gabor]

Like this 2 secret idea and like the 2factor auth also even it is from gauth or other like yubikey

The problem with secrets is that you can "crack" them without trying. It's perfectly possible that two users can end up with the same secret and thus see eachothers files. Ofcourse the chances are slim, but they do exist. Rather than creating stronger secrets where the collision chances are reduced I would like to see a system where there are two secrets and you need them both to access files. The first secret is generated by Bittorrent and is checked against a database to make sure it's unique. The other is user generated and doesn't need to be unique. Same as a username and password except the username is just a random string.

[GreatMarko]

The problem with secrets is that you can "crack" them without trying.

Not if the length of Secrets was improved - I'd like to see someone try crack a secret of length of let's say 512 characters (including symbols!) - rather than just the current 21 alpha-numeric character secrets!

I would like to see a system where there are two secrets and you need them both to access files. The first secret is generated by Bittorrent and is checked against a database to make sure it's unique. The other is user generated and doesn't need to be unique. Same as a username and password except the username is just a random string.

For this to work, the service would rely on a connection to BitTorrent, and your details stored there in a database! I would suggest that this is actually LESS secure than being responsible for your own unique secrets that only you generate and use.

The whole point of SyncApp is that it doesn't require a central server (or any connection to the internet for that matter - you can sync directly accross a LAN!)

As I said previously, SyncApp needs to be both secure AND user-friendly. I don't think users would like the idea of their secrets being "checked against a master database at BitTorrent" as it were... and beside I still don't see the need for this as long as SyncApp removes the current 21 alpha-numeric limit on secrets, to allow you to generate/manually enter secrets of any length, and include symbols as well. Seriously, it would take decades for the best super computers in the world to "guess" an extremely long secret!

[rdebath]

The secret is (obviously) a 128bit base64 code. As such is IS secure with an 'impossible' level chance of a collision as long as you don't treat it as a plain password.

So do this ...

$ echo -n This is a very long password just for you | md5sum

e9112e7f0c3401113bacfced199308a4 -

$

Then convert it to get this as your secret ... 6REufww0ARE7rPztGZMIpA==

I think you need to trim off the '=' characters.

The wishlist is for this conversion to be available as a 'secret_as_passphrase' item.

[kos13]

We are going to change the way Secret works in next build. We will:

- remove restriction on the length;

- will use base64, so all bits will be used

- will introduce one time passwords to safely pass secret over insecure media.

[rdebath]

"one time passwords to safely pass secret over insecure media."

Could you explain this a bit, I mean I understand the "secret" is used to generate the rendezvous key (ie "info hash" equivalent) so you have to know it to be able to find the peers. This kinda conflicts with having some other password.

Would it be like the SSL certificate signing process where the Alice sends out an encrypted request to "Trent" who signs it offline and returns the signed message to Alice. Alice unwraps it and is able to prove themselves to Bob or any other member of the "swarm" (connected to via publicly released "info hash") because the key is signed by Trent.

[kos13]

One time password - is shorter secret that could be used only once. When you generate OTP on one device it will wait till the first device is connected using this OTP, and then will provide full Secret to this device over secure channel. This way OTP password can be shorter, easier to enter, plus you could distribute it over IM or email, since it will become useless after first connection of device.

[rdebath]

Hmm, okay. Thank you.

But, I suspect I'd use a PGP mode to send the real key.

[Tsu]

Not if the length of Secrets was improved - I'd like to see someone try crack a secret of length of let's say 512 characters (including symbols!) - rather than just the current 21 alpha-numeric character secrets!

Problem is that they don't need to crack, can be an unlucky collision. Chances are small but they are still there if there is no way to guarantee a unique secret.

For this to work, the service would rely on a connection to BitTorrent, and your details stored there in a database! I would suggest that this is actually LESS secure than being responsible for your own unique secrets that only you generate and use.

The whole point of SyncApp is that it doesn't require a central server (or any connection to the internet for that matter - you can sync directly accross a LAN!)

But how does SyncApp know which computer has the files beloning to my secret? If I enter my secret on another computer the original computers need to know what computer was added and how to reach that computer.

And it wouldn't be less secure if it used two secrets. Compare it to having an account for each computer to log on to and from which to manage sharing folders with other accounts and a seperate secret that is also needed to access folders but isn't stored centrally.

As I said previously, SyncApp needs to be both secure AND user-friendly. I don't think users would like the idea of their secrets being "checked against a master database at BitTorrent" as it were... and beside I still don't see the need for this as long as SyncApp removes the current 21 alpha-numeric limit on secrets, to allow you to generate/manually enter secrets of any length, and include symbols as well. Seriously, it would take decades for the best super computers in the world to "guess" an extremely long secret!

It will take decades for a super computer to guess that specific secret but it can take but a second for a random computer to accidentally generate a secret that is allready in use somewhere else. Give a thousand monkeys a thousand typewriters and there will be a day when a monkey writes Hamlet.

With no guarantee that a secret is unique there will always be a change, however small, that someone will get your files.

[kos13]

Problem is that they don't need to crack, can be an unlucky collision. Chances are small but they are still there if there is no way to guarantee a unique secret.

But how does SyncApp know which computer has the files beloning to my secret? If I enter my secret on another computer the original computers need to know what computer was added and how to reach that computer.

There is no service that guarantees uniqueness of private key that is used by certification authority, your bank, NASA, FBI, White House or any other organization. So how they could be sure that nobody will crack it in unlikely collision? And there are teams, organizations and countries that intentionally want to crack it. Without any luck, so far.

SyncApp allows you to use your own key of any length. We are sure that key of 21 truly random bytes are enough, but you are free to use any key you want.

And it wouldn't be less secure if it used two secrets. Compare it to having an account for each computer to log on to and from which to manage sharing folders with other accounts and a separate secret that is also needed to access folders but isn't stored centrally.

One time password's goal is to avoid exposing secret to insecure media like emails or IM. So, if somebody will gett access to your email, he won't be able to reuse the one time password to connect to your computers.

It will take decades for a super computer to guess that specific secret but it can take but a second for a random computer to accidentally generate a secret that is allready in use somewhere else. Give a thousand monkeys a thousand typewriters and there will be a day when a monkey writes Hamlet.

With no guarantee that a secret is unique there will always be a change, however small, that someone will get your files.

All security is based on the fact, that probability of discovering encryption key is so close to 0, so everyone could sleep at night

But let me ask you a question.

Assume person has less than 10 characters before @ in his gmail address, strongest possible password and it is 11 bytes. What will be easier to crack SyncApp secret or his Dropbox/Gmail/Bank account?

[Tsu]

But that is in case of someone actually trying to crack my e-mail or Dropbox account. They can't access my e-mail account my random luck because a username and password match has to be made. In the case of a secret they only need to randomly get the same secret as me. Chances are slim but they do exist right?

[GreatMarko]

Chances are slim but they do exist right?

Yes, but the point is NO system/app can guarentee 100% "unbreakable/uncrackable" passwords/codes/secrets - however you want to term it!

As Kos has made quite clear, SyncApp will allow "you to use your own key of any length. We are sure that key of 21 truly random bytes are enough, but you are free to use any key you want."

So there will be nothing stopping you having a secret with a length of 256 characters, 512 characters, 1024 characters, 2048 characters... or more!! Let's take a very simplified example - let's say each character of a secret can be one of 62 possible chracters (a-z, A-Z, or 0-9) (in reality there would be more than 62, as symbols, etc are soon also to be allowed) - but let's just stick with each character of a secret being one of 62 possible characters.

Therefore,

A 1 character long secret would allow for 62 unique "secrets"

A 2 character long secret would allow for 3,844 unique "secrets"

A 3 character long secret would allow for 238,328 unique "secrets"

A 4 character long secret would allow for 14,776,336 unique "secrets"

A 5 character long secret would allow for 916,132,832 unique "secrets"

A 6 character long secret would allow for 56,800,235,584 unique "secrets"

...and so forth!

So hopefully you can see that as the length of the secret increases by just 1 character, the chances of "guessing"/generating/inputting the same secret as someone else decrease exponentially! - and right now SyncApp is generating secrets of 21 character length (the number of unique "secrets" this offers is a number too large for me to express here!)

Even so, by removing the current 21 character secret length limit (which Kos has confirmed is happening) AND allowing symbols, etc in secrets (which Kos has also confirmed is happening) SyncApp is going to be even more secure!

But at the end of the day, If you're then still worried about someone potentially "guessing" your SyncApp secret, or SyncApp inadvertantly generating the same secret as one of your folders for another user... the answer is simple... don't use SyncApp! No-ones forcing you too!!

[kos13]

They can't access my e-mail account my random luck because a username and password match has to be made. In the case of a secret they only need to randomly get the same secret as me.

Consider this string uuuuuuuuuuPPPPPPPPPPP. This is 21 characters long alpha numerical string. What are the chances that if I randomly generate this string and will use it as uuuuuuuuuu@gmail.com with password PPPPPPPPPPP I will crack someones gmail account?

Just think about email and password combination as one string. something like youremail@gmail.comAndHereGoesMyPassword I randomly generate this string and try to find a collision with someones gmail account. What are my chances?

Cracking SyncApp secret significantly harder, since it uses all bits in byte, while gmail uses only letters, numbers and some special symbols, so it uses not all 8 bits.

Since we removed limitation on Secret length, you could add email in front of 21 characters Secret and use it as your Secret, so people have to guess your email and Secret.

[MonoTouch]

I agree that individual security is given.

However, the comparison given here is not completely right: a Google server will increase the login time after each a wile. In syncapp this is not the case (as i understand). So a bruteforce attack is faster in this case. Additionally there are typically several nodes, allowing a distributed attack.

Another thing: If enough people using it and having several shares there will exist a lot of secrets. If I'm not interested in a specific person I can just bruteforce against all syncapp users and see what I can find.

I know I don't have to use syncapp, but we all want to help to design a better product - right? =)

[kos13]

We do talk about two different scenarios:

1. Tsu, was talking about the case, that someone will hit the same secret unintentionally. I.e. not trying to hack (brute-force) a specific account, but rather will hit the Secret that is already used by someone. In such a case you just hit the right combination. Google protection against of brute force won't help in such case.

2. Brute-force attack. We already have brute force protection on server, and maybe will add it to client later. However, using brute-force attack against of at least 21 bytes random key, that requires at least 20 ms to verify 1 combination, doesn't make any sense at all.

Why Google introduced protection against of brute-force attack? Because users use passwords like "123", "password", "hello123". In this case, brute-force attack based on vocabulary is very effective.

Developing login/password authentication is simple, everyone uses it and concept is well known to users. However it is so insecure, that we decided to go hard way and introduced concept of Secret to mass market.

We would take time to explain any single security concern you might have. Secret approach is by far more secure than any login/password solution. It is in line with RSA private/public key authentication, which is a strongest authentication from a security perspective.

[rdebath]

>> Chances are slim but they do exist right?

I'll try this.

If I'm talking to a non-technical person the answer is NO; you would say that there's NO chance of it happening.

For example, lets assume that the chance of it happening is a billion to one, literally make 1000000000 attempts and one of them would succeed. Now this is actually a common lay person's shorthand for not just "impossible" but "so impossible I don't want to talk about it". The problem is it's not really impossible, in mathematically terms it actually just "quite unlikely". You see if there were really one chance in a billion that (say) somebody is born with stripes there would actually be six or seven stripped people in the world.

>> It will take decades for a super computer to guess that specific secret

The numbers here are far larger than that one of them is:

three hundred fourty undecillion two hundred eighty two decillion three hundred sixty six nonillion nine hundred twenty octillion nine hundred thirty eight septillion four hundred sixty three sextillion four hundred sixty three quintillion three hundred seventy four quadrillion six hundred seven trillion four hundred thirty one billion seven hundred sixty eight million two hundred eleven thousand four hundred fifty six.

The this is the sort of number that cryptologists think of as like "impossible". It wouldn't just take mere decades for some existing supercomputer to break it. The idea is like "NO supercomputer will break this within the next billion years" and the numbers are big enough that even if aliens arrive with some wonderful new tricks the lay person's answer will still be; "it'll never happen".

To get some idea of the sizes of the numbers involved you might have a look at the problem of "The second half of the Chessboard" .

https://en.wikipedia.org/wiki/Wheat_and_chessboard_problem#Second_half_of_the_chessboard

Then scare yourself with the realisation that we're talking about the third and fourth "halves" of the chessboard ...