Can someone just guess shared secrets?

[antwerpenr]

Maybe I am missing something but can someone not just guess shared secrets?

OK - they are random 32 character strings but if I start guessing at random I suspect that before too long I will hit one that is used by somebody.

So whilst it might be hard (impractical) for me to guess a particular person's folder code surely it is quite possible to land some data that I should not be intended to see.....

[Shish]

If every person on earth had 1,000,000 unique shares, and you were making 1,000,000 guesses per second, it would be an average of 1079028300 years between each hit

(Numbers not completely pulled from my ass, but there are some approximations there, like assuming the world has a population of 10 billion because dividing by 10 is easier than dividing by 7 If someone wants to be more accurate go ahead, though I'm fairly sure I'm in the right ballpark)

[antwerpenr]

OK... sounds like quite a challenge. Still somebody wins the lottery most weekends (or even just now and then) so without a second factor it is quite possible (however unlikely) that somebody will find my data (even if they were looking for something else)..... right?

For those who wish, would it not be a good idea to allow/require the use of some second factor?

[eseelke]

I think it might be better to have a system similar to the Amazon S3 service. They require two keys for authentication, an access key and a secret key.

Because if you have millions of people using BitTorrent Sync, chances are someone will eventually end up in another's shared folder just by hitting generate key.

[GreatMarko]

There's several other threads already covering/discussing this topic, the most active is the "Security" thread.

[Shish]

Still somebody wins the lottery most weekends

The lottery is one in ~14,000,000. This is one in ~3,400,000,000,000,000,000,000,000,000,000,000. The odds of a random btsync collision are in the same region as the odds of everybody on the planet winning the lottery at once

chances are someone will eventually end up in another's shared folder just by hitting generate key.

If you're willing to wait longer than several lifetimes of the universe before it happens once, then yes, it will happen "eventually".

I get the point you're trying to make -- that if everybody prefixed their secrets with their username (for example), then there would /never/ be any collisions; but that isn't actually true, because of brute forcing and typos -- and the odds of somebody either brute-forcing or typoing an 8 character username + 8 character password that collide with someone else's are considerably higher than doing the same for a 32-character secret. In the end, it's only the /total length of all login details combined/ that matters, and so btsync's idea of "one long secret" is considerably stronger than the traditional "short username + short password".

[rdebath]

... 1079028300 years ... I'm in the right ballpark)

I get the number 6616168750430111230.745454119955558193835030312378439183063621313089

ie: 2^160 / 1000000 / 1000000 / 86400 / 365.2422 / 7000000000

Quite a bit bigger.

But we have no guarantee of the quality of the random number generator, it looks like it's using OpenSSL and that has a good one. But that's the same one Debian was using when they had their little problem with keys having only 15 bits of entropy...

[dsl]

Would some skilled hacker be able to phish shared secrets from btsync installations using tracker server and DHT?

[bobjects]

"For those who wish, would it not be a good idea to allow/require the use of some second factor?"

The first 16 characters are your first factor, the second 16 characters are your second factor.

The big question is whether the program uses a cryptographically strong random number generator. I don't know the answer to that.

[kos13]

Sync uses strong random generators.

Mac, Linux: /dev/random

Windows: CryptoAPI

[rdebath]

Would some skilled hacker be able to phish shared secrets from btsync installations using tracker server and DHT?

No. The infohash sent to the tracker is the SHA?(secret) you would have the "reverse" the sha function. This is only possible if the secret key has a very low entropy. (easy to guess)

I did a little test; we seem to be okay on Linux at least; 4 million keys no duplicates what so ever.

A simple frequency test of the file looks fine ...

4859475 2

4863241 3

4860436 4

4859986 5

4857776 6

4857271 7

4858194 A

4856963 B

4857042 C

4859213 D

4859448 E

4860727 F

4856947 G

4858735 H

4863173 I

4856017 J

4858412 K

4864000 L

4858075 M

4859043 N

4859248 O

4854939 P

4857153 Q

4860129 R

4858500 S

4856507 T

4860618 U

4859425 V

4858419 W

4857521 X

4858505 Y

4858702 Z

[AlexL]

While I am absolutely certain that none would be able to guess MY hash, I believe that the hash can be guessed by any schmuck with a random number generator.

So, I do the same procedure as with Dropbox, I either do not store anything sensitive (mp3 playlist) or have a truecrypt container in the sync folder.

[Shish]

Suddenly I understand why highschool physics teaches children things that are aren't true. Having people learn something that is /close/ to the truth is much more useful than giving them the full truth and having them not understand any of it...

With that in mind:

Highschool explanation: No, your hash cannot be guessed.

University explanation: Realistically, within the lifetime of this universe, your hash cannot be guessed.

[affinity]

The size of the secret is almost irrelevant, if people use the standard 32 character Base32 set and don't opt to use >40 character Base64, then they will /always/ be at risk of a lotto winner. A properly implemented two factor auth will not accept one factor unless both factors are correct -- using Google signin with GA will accept your login first, then it will ask for the simple 6 digit TOTP code; of course that is better than not using any two factor (although you already have somewhat two factor with username and password before you get to the 6 digit factor, that is time limited, but only protected by a 16 alphabetic character string).

Anyway, what I've proposed in another thread is that you should have the ability to "lock" the system and only allow new connections when the system is unlocked and you can watch for each new connection -- each new connection gives a UUID number that, once authorized, will be able to get in when the system is re-locked again. It solves the lotto winner problem. Without such a mechanism, then lotto winners will arise, no matter how unlikely, it will always remain possible -- so you need to encrypt all your files before you place them into a sync folder or use a Truecrypt (or similar) container.

[Shish]

using Google signin with GA will accept your login first, then it will ask for the simple 6 digit TOTP code

And what if someone guesses the username, password, and TOTP code?

each new connection gives a UUID number that, once authorized, will be able to get in when the system is re-locked again. It solves the lotto winner problem

And what if someone guesses the UUID that allows them to get into a locked system?

so you need to encrypt all your files before you place them into a sync folder or use a Truecrypt (or similar) container.

And what if someone guesses your truecrypt passphrase?

[affinity]

The combination of username (email address), password _should_ be tough if you use strong passwords; the TOTP code cycles over time, so long as you never broadcast your code at a guessable time (like on a video blog), then your 16 character code used to "secure" the TOTP installation will be safe. Guessing the TOTP code will be harder for the lotto player to succeed as the code is specific to the user account and time based. The randomness of a true lotto winner is quite different, it targets ANY potential secret, not a specific one.

Guessing the UUID is a similar problem space, you first need to know you have a hit with the secret -- then you either guess of brute force the UUID; so again, a very targeted approach, rather than a purely random, find a winner for any secret.

Truecrypt can be well secured with a very long pass phrease AND you can use key file(s) too; so long as you do use a suitably long pass phrase and you use a suitable key file, then you should be very safe from a targeted attack particularly.

[AlexL]

Have a long randomgenerated password that you then put in LastPass+yubikey and you have a pretty good security right there!

[affinity]

Have a long randomgenerated password that you then put in LastPass+yubikey and you have a pretty good security right there!

It doesn't matter how good your secret is, if you can create it, so can a lotto winner. Lock / Unlock .....this will fix the problem

Of course, you will be much better off with your own generated key, provided it is long enough and not the standard Base32 32 char one.

[rdebath]

You guys!

Okay try this, it's a javascript application (ie: run totally in your browser; even offline) that takes your wonderful truecrypt passphrase applies the same conversion truecrypt does to get a key and converts the key into a form acceptable to BTSync.

Truecrypt hashes it's passphrase into a fixed length key, just like the BTSync key.

Happy ? http://www.debath.co.uk/MakeAKey.html

PS: Ooops, should have looked first. Truecrypt uses RIPEMD-160 not SHA1 (160) ... close enough.

[Shish]

The combination of username (email address), password _should_ be tough if you use strong passwords; the TOTP code cycles over time ... Guessing the TOTP code will be harder for the lotto player to succeed as the code is specific to the user account and time based.

So username + password + code + correct time to enter code... are any of those things *impossible* to guess correctly? Nope. It's extremely unlikely, but getting in by guesswork is possible in theory.

The randomness of a true lotto winner is quite different, it targets ANY potential secret, not a specific one.

Why do we need to target? Just generate those 4 bits of data over and over again, all of them at random, eventually you'll find a match ("eventually" may mean "longer than the life of the universe", but it can happen in theory)

Guessing the UUID is a similar problem space, you first need to know you have a hit with the secret -- then you either guess of brute force the UUID; so again, a very targeted approach, rather than a purely random, find a winner for any secret.

Again, no you don't. Just randomly pick a secret+uuid, if it doesn't work, pick a new secret+uuid. Realistically you're never going to get both correct through pure guesswork; but realistically, you're never going to get a btsync secret correct through pure guesswork either.

Truecrypt can be well secured with a very long pass phrease AND you can use key file(s) too; so long as you do use a suitably long pass phrase and you use a suitable key file, then you should be very safe from a targeted attack particularly.

And again, a long pass phrase is /unlikely/ to be guessed, but is it *possible* to guess? Sure is. A key file? It's just data, that can be guessed too.

... so yeah. *nothing* is 100% immune to guesswork. But btsync is already 99.99999999999999999999999999999% immune, which is enough that basically ever other possible attack is more realistic, and it's a waste of time to worry about this one.

[affinity]

If you have a long secret, and I mean really long, say 80+ Base64 chars..... then trying that with a UUID is even more "virtually impossible", but yes it is possible for a lotto winner, however unlikely. If the UUID is long enough, then it would likely be safe even if the secret was accidentally leaked -- the UUID could just as easily be another 80+ Base64 chars, so effectively two secrets to find, doubly secure against random discovery. In any case, it is clear that secure data needs to be secured in other ways than just a single secret (no matter how long the secret is).

[Shish]

In any case, it is clear that secure data needs to be secured in other ways than just a single secret

Seems like you've started with that assumption in mind, ignored evidence against it, not given any evidence for it, and then declared it correct :-|

("I don't understand the maths, but my gut tells me [blah]" is not evidence)

On the contrary, "one (sufficiently long) secret" is the most secure thing we have -> https://en.wikipedia.org/wiki/One-time_pad

(To be clear: there are plenty of pros and cons for other authentication schemes - but in this thread I'm only talking about being able to guess access codes)

[affinity]

Facts are facts, whilst a random collision is possible, there isn't much choice if you must secure your data. Still.... lock / unlock would go a long way to fixing the potential, even if extremely unlikely, possible hole.

[Shish]

I'm going to assume you're trolling at this point, but for the sake of clarifying the issue for future readers:

Facts are facts, whilst a random collision is possible, there isn't much choice if you must secure your data. Still.... lock / unlock would go a long way to fixing the potential, even if extremely unlikely, possible hole.

No.

It would not.

Seriously, it wouldn't. You can stop thinking it would now, because it won't. Go take a math class and re-read my posts if you don't get why.

At best, you're taking sub-atomic-sized security hole that nothing in this universe can fit through, and making it half the size. In exchange, the process for authenticating becomes more complicated, and the odds of a bug in the code (which is approximately infinity times more likely and infinity times more dangerous) go up. Meanwhile, the realistic attacks like a virus stealing your secrets remain as they were. It really isn't a worthwhile trade :|

(Again, there are benefits to other auth schemes; but protection against guessing a key isn't one of them)

~

Bonus problem! Assuming that any of these suggestions for "stopping" guesswork attacks actually worked (they don't, but let's imagine) - how does one implement any of them in a strictly decentralised way, as is the main selling point of btsync?

[rdebath]

Anyway, what I've proposed in another thread is that you should have the ability to "lock" the system and only allow new connections when the system is unlocked and you can watch for each new connection -- each new connection gives a UUID number that, once authorized, will be able to get in when the system is re-locked again. It solves the lotto winner problem. Without such a mechanism, then lotto winners will arise, no matter how unlikely, it will always remain possible -- so you need to encrypt all your files before you place them into a sync folder or use a Truecrypt (or similar) container.

This idea will decrease the security of the share, because there are now multiple passwords that will allow someone to connect. Each "UUID" is a freshly generated random password. In fact if it's a standard UUID it's only 128 bits long compared to 160 for a BTSync password AND if generated by traditional means a UUID is likely to be guessable because it often relies on ethernet adaptor IDs and the time for large portions of it's uniqueness.

If you want individual control of who is able to connect you have to use a certificate style scheme so everybody can authenticate peers trying to connect to them without knowing all the passwords or having to depend on a central authentication agent. Even then distribution of the certificate revocation list is a significant problem.