mrf

Members
  • Posts

    5
  • Joined

  • Last visited

Posts posted by mrf

  1. Oh, I completely missed that, sorry. Well, one way of doing it would just be to change the length from 32 to 128 or larger (In the generation code, which, apparently I can't find in the javascript. I gave up after ~ a minute), another way is to just say "Security isn't automated, do it yourself" and let users do it themselves.

    I know I changed my secret, and, I'm sure you did to. I understand not everyone will, but, that's kind of their fault. I do agree though, however, I dislike having to have the same folder names (As I believe that's what you're saying?)

    Yes, I sure changed my secrets length. And yes, the folders with the same names would be the idea.

    Sync use AES encryption.

    The transport is AES encrypted, not the secret though it's a 32 bit Base64 phrase, which is nowhere near as secure as AES. Aren't you a team member? You should know this.

  2. Correct me if I'm wrong, but, you can specify your own value > 32 characters?

    Yes, as I said:

    I know that the length of the key is variable and thereby can be changed by the user, which everyone should be doing right now, but that's not enough for the ones using the generated secrets.
  3. @verloren: Your calculation is for a directed attack on one key. We are talking about undirected attacks here. You are forgetting that with every added shared folder the chances are doubled. --> The more folders are shared the easier it becomes to guess a random key. With no secondary security in place BitTorrent Sync will just become less secure with more users and more folders shared.

  4. I have major problems with the security in BitTorrent Sync:

    Currently a "secret" that is generated by the sync app is a 32 character Base64 phrase.

    Now, targeted attacks might be very hard or near impossible without the attacker having more information, but untargeted attacks by just guessing ramdom keys en masse are very possible and likely.

    Example:

    Machine A: A folder with the name "my_synced_files" is shared with a "ramdom" Base64 secret. The users tells the owner of machine B about this.

    Machine B: A folder with the name "new folder" is created and the same key is saved for it. --> It works!

    Machine C (the evil haxor): Tries to brute force the random secrets. He knows that 32 chars in Base64 is having a good chance. So he automates (for example with: Linux, Python, Selenium, the web UI) the creation of the phrase and tries them out on a folder until something works. I works in time!

    Also likely are accidental key collisions, depending on how many users share how many folders. The more folders are shared the higher the chance of 2 equal keys generated by different users.

    I know that the length of the key is variable and thereby can be changed by the user, which everyone should be doing right now, but that's not enough for the ones using the generated secrets.

    A simple and effective way to make these random attacks much harder would be to enforce the name of the shared folder to be the same on all machines in combination with the secret.

    Example:

    Machine A: A folder with the name "my_synced_files" is shared with a "ramdom" Base64 secret. The users tells the owner of machine B about this.

    Machine B: A folder with the name "my_synced_files" is created and the same key is saved for it. --> It works!

    Machine C (the evil haxor): Tries to brute force the names of the folders and the secrets, but is unsuccessful for a long time, because now it's much harder.

    The changes for the Bittorrent Sync API would be minimal as only the Sha2(foldername) would have to be added everywhere.

    Currently: SHA2(Secret):ip:port
    Possibly: SHA2(Secret):SHA2(foldername):ip:port

    What do you think?

    PS: I mean the folder basename not its path. So /home/user/Syncme/my_shared_folder should become my_shared_folder for use in this case.