Disappointed Cat

Members
  • Content Count

    299
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Disappointed Cat


  1. So he just enters the secret (which he knows) on another machine, or renames his device. Then what?

    Good point. How could I not think of that?

    By that time all other clients should be using the new key. If there is a client with the old key and there is none currently online with the new key then they would keep sharing until one comes online. Or maybe the revoked client could be tricked into leaving the swarm. Also it wouldn't just work with the device name only and it's supposed to be transparent so the client being revoked wouldn't know until it's too late.

    Anyway, this is an idea born dead.

    Maybe custom trackers could be used for optional central management one day.


  2. Even though lock/unlock is totally unnecessary, the ability to ban peers from the swarm could be really useful.

    For example If I want to revoke access from a peer I'd have to change the secret everywhere.

    I think this could be propagated throughout the peers. Banning clients is just as much pain as lock/unlock but sending out a new secret excluding the revoked clients, the rest could transparently change the secret to a new one. Now I don't know if this could be implemented securely but if yes this is a must have.


  3. Good points and I completely agree with you.

    But to keep the interesting discussion rolling: (In a targeted attack scenario.)

    The attackers know the secret is 32+ alpha-numeric characters and they easily have the hash and know the hashing algorithm. Let's assume they have quantum or alien technology ahead of this time. There won't be many hash collisions with the given length of the secrets so even if they have to send packets to verify the secret it's only a few times. Of course we're way out of the ballpark here. Heck they could even compromise the tracker(s) and brute force all valid hashes. :)

    Secrets could be further strengthened if the app would do say 10 million rounds on it before generating the final key. So it would be pointless to try and brute force the secret instead of brute forcing the absolute entire key space. Not much and useless with self-generated longer secrets - just a thought.

    Back in the real world any possible breach will be because of users sending secrets in plain text everywhere.


  4. Indeed. Thanks for bringing it up.

    I just switched to it so I can use my global base auth configuration with fail2ban.

    If anyone is interested in this, here's how:

    * Configure base auth like you'd normally do in a location or directory block.

    * Send btsync a static auth header: STRING=BASE64(user:pass)


    AuthUserFile /etc/apache2/htpasswd
    AuthGroupFile /etc/apache2/htgroup
    AuthName "asdfs"
    AuthType Basic
    Require group admin
    RequestHeader set Authorization "Basic STRING"

    This also sort of eliminates the problem of btsync stroring passwords in clear text. Listening on localhost only..

    You can set it to any dumb thing and just authenticate over the proxy.


  5. I used Notepad++.

    * Insert the certificate text after selfcertLEN: - after removing the original of course.

    * Apply unix EOL conversion.

    * Then select the inserted text (including the last new line) and write the length after 'selfcert' and before the ':'.

    (The status bar will show how many characters you selected.)

    Like this - first the public, then the private key:


    selfcert1880:-----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    -----BEGIN RSA PRIVATE KEY-----
    ...
    -----END RSA PRIVATE KEY-----

    As for the RSA part: It didn't work for me if I only wrote BEGIN and END PRIVATE KEY as it is in the original file.

    Edit: You did try to access it via https://host:8888/ right?

    If you want to ommit the port you'd need to change the webUI's listening port to 443,

    assuming it wouldn't collide with your webserver.


  6. If we're talking about theory and what ifs then it's worth mentioning that quantum computers may be only 5-10 years away. That halfs the time needed to brute force keys so we would need 256 bits to be as secure in the post-quantum age as with 128 bits now. Prime factor based public keys will become vulnerable too. The good question is who will be able to afford them. Google and NASA already has a joint project going to research machine learning.


  7. If you're using Windows you can try junction points (mklink /J name target) for the same effect.

    Actually, even BTSync synchronizes them because it can only recognize unix symlinks but not windows symlinks.

    Edit: It appears Dropbox takes more resources when syncing a folder with a SyncID file, but it's still low.

    It's probably because both apps are checking the lock on the file.


  8. I found a few .!sync files lying around for weeks. I think this is a byproduct of changing,

    deleting files while they're being synced - most of them were deleted files.

    If not removing derelict .!sync files is intended then there should be a feature that notifies the user about them.