Jump to content


Become a part of the community today! Registration is quick and easy and will enable you to post, send personal messages, and join in on the chat! It's as simple as clicking on the links above.

Can someone just guess shared secrets?

security risk

  • Page 1 of 4
  • 1
  • 2
  • 3
  • Please log in to reply
62 replies to this topic

#1 antwerpenr

antwerpenr

    New User

  • Members
  • Pip
  • 3 posts

Posted 07 May 2013 - 02:34 PM

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.....

#2 Shish

Shish

    New User

  • Members
  • Pip
  • 8 posts

Posted 07 May 2013 - 02:46 PM

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 :P If someone wants to be more accurate go ahead, though I'm fairly sure I'm in the right ballpark)
  • florin81 likes this

#3 antwerpenr

antwerpenr

    New User

  • Members
  • Pip
  • 3 posts

Posted 07 May 2013 - 02:55 PM

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?

#4 eseelke

eseelke

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts
  • LocationCorpus Christi, TX

Posted 07 May 2013 - 03:00 PM

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.
  • Xanza and btusername like this

#5 GreatMarko

GreatMarko

    BitTorrent Sync Alpha Tester

  • Moderators
  • 2,218 posts
  • LocationUK

Posted 07 May 2013 - 03:00 PM

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

#6 Shish

Shish

    New User

  • Members
  • Pip
  • 8 posts

Posted 07 May 2013 - 04:40 PM

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 :P

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".
  • yottabit likes this

#7 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 07 May 2013 - 04:47 PM

... 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...

#8 dsl

dsl

    Member

  • Members
  • PipPip
  • 16 posts

Posted 07 May 2013 - 08:34 PM

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

#9 bobjects

bobjects

    New User

  • Members
  • Pip
  • 3 posts

Posted 08 May 2013 - 03:04 AM

"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.
  • bradmurray likes this

#10 kos13

kos13

    BitTorrent Sync Team

  • Employees
  • 693 posts

Posted 08 May 2013 - 05:51 AM

Sync uses strong random generators.

Mac, Linux: /dev/random
Windows: CryptoAPI

#11 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 08 May 2013 - 05:55 AM

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

#12 AlexL

AlexL

    New User

  • Members
  • Pip
  • 8 posts

Posted 08 May 2013 - 07:29 AM

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.

#13 Shish

Shish

    New User

  • Members
  • Pip
  • 8 posts

Posted 08 May 2013 - 10:24 AM

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.
  • bradmurray, ojchase, yottabit and 1 other like this

#14 affinity

affinity

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts
  • LocationMelbourne AU

Posted 08 May 2013 - 10:38 AM

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.

#15 Shish

Shish

    New User

  • Members
  • Pip
  • 8 posts

Posted 08 May 2013 - 11:35 AM

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?
  • ojchase and bobjects like this

#16 affinity

affinity

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts
  • LocationMelbourne AU

Posted 08 May 2013 - 12:08 PM

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.

#17 AlexL

AlexL

    New User

  • Members
  • Pip
  • 8 posts

Posted 08 May 2013 - 01:17 PM

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

#18 affinity

affinity

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts
  • LocationMelbourne AU

Posted 09 May 2013 - 01:12 AM

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.

#19 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 09 May 2013 - 07:21 AM

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.

#20 Shish

Shish

    New User

  • Members
  • Pip
  • 8 posts

Posted 09 May 2013 - 10:00 AM

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.


  • Page 1 of 4
  • 1
  • 2
  • 3



Also tagged with one or more of these keywords: security, risk