affinity
-
Posts
69 -
Joined
-
Last visited
Posts posted by affinity
-
-
-
The fact that any new secret creation can cause a collision is enough to need some other factor.
I don't want Google Authenticator, which by the way, can be fully implemented WITHOUT using ANY Google servers. The code to use this kind of time based one-time-password is known, in fact I use a plugin with KeePass to generate TOTP codes when required for Gmail and other services, rarely do I bother with the GA app on my phone for the code.
If you have the 16 character string that is used by GA, then you no longer need Google at all, in fact, even if you do use the GA app, then the generated key is done on your device without communicating with Google (if the app does actually communicate with Google, then it is an "extra" that isn't required to satisfy the requirement).
Definitely, this post from the other thread indicates what I think will be the best way to deal with ANY possible collision (not talking at all about brute-force here, only accidental collision(s).
http://forum.bittorr...__40#entry48294
This too:
-
Definitely, lock and unlock works for me with folder UUIDs-- if you get in when it is unlocked, then the "owner" can see and accept your entrance, then store your UUID to allow you to connect again at any time in the future when the setup is otherwise locked from new users.
And sure, a very long key, much longer than the default 32x base32 chars .... there is only ONE base32 character set, it includes A-Z and 2-7 only -- so, no zeros or ones to confuse with the letters O and I.
Certainly use base64 and very long keys and your chance of a random clash is virtually impossible, but a lock/unlock mechanism will make it absolutely impossible when the "owner" watching each new connection during a period of the system being unlocked.
Alternative base32 sets are not base32 exactly, see this link:
https://en.wikipedia...Base32_alphabet
I think unless it is otherwise stated, then the RFC standard should be used, which is very clear as to which characters are used.
Any use of Base32 or Base64 will allow for very long passwords and use of entire bit space, the 21 character full bit space translates to 32 characters of Base32 ... so you are not losing bits if you lengthen the secret appropriately.
-
Would it be possible to have two instances running on the same machine with different user login credentials?
-
Yes, the RPI is a great little device, but it is power challenged -- great for some tasks, but too slow or resource intensive for other uses.
-
-
I believe the cloud icon indicates that the data is going through BT servers because a direct connection cannot be made.
-
For Linux users, why aren't you using rsync over ssh? There are lots of options for handling UIDs and other things. The only thing about running rsync is that it isn't live updates like btsync.... I use rsnapshot to backup Linux machines, it does so with intervals like hourly, daily, weekly, monthly and yearly; it uses rsync to do the job -- but that's nothing like btsync.
-
The "stock" standard master secrets are 32 characters of base32 form -- that covers upper A-Z and 2-7 .... no zeros, no ones, everything is readable by a human (without confusion).
Now there are a great deal of combinations in play here, but it only takes ONE collision to randomly occur and you can expose a bunch of otherwise private files. The 32 characters gives 160 bits coverage.... that is the weakest link, it doesn't matter that transfers are done using AES-256 if the secret is shorter and the secret is ALL that is required to gain access to the folder -- once you have access, the encryption could be AES-1024, it wouldn't matter, you already have access (through the weakest link).
I do like the idea of public/private keys and I would be more comfortable with that as a second factor of authentication; but it can get too complicated for the masses. To keep it simpler, a list of authorized email addresses for a secret would virtually guarantee that you will be extremely safe from any possible random collision. You need the nice long secret AND you need an approved email address or you've got no access. The "email addresses" don't even have to be real, although it might be better if they were. Of course there will still be a problem if an email was intercepted (at any point) and such email had the secret key passed in clear text, unless fake email addresses are known to be required to connect and the fake email addresses are given via other means (not via email).
On the public/private key idea, it would be good if an ssh like authorized_keys file could be kept, the only trouble with that is that it is hard to know which line belongs for which authorized accessor ... unless you keep good track of each public key component otherwise....
The first creator of a secret key must become the "owner" and there needs to be a simple /hidden/ or otherwise special file in the master shared folder with a list of approved email addresses that will never be sent to another machine. ever.
And it will be a WPS type failure if a secret was said to be okay and then the email address was asked for. Both need to be confirmed as 100% correct as a pair before a denial or acceptance response is given.
If private/public keys can come into play, then an ssh style authorized_keys file could easily be used at the master end.
-
Odd, my pid file has the right date/time.
-
Did you try putting a comma at the end of the line?
-
Well, the Linux port uses it's own built-in webserver to mange secrets and folders; creating the folder might be a problem, but perhaps not?
-
Yes, but if it is using different instances and different ports, then each instance can behave as a distinct computer.
-
It would be good to use a filter like .rsync-filter with include/exclude processing.
This gives some examples for using .rsync-filter files with rsync:
-
It would be helpful if you can run multiple copies of BTSync.exe -- then perhaps you could do a sync operation b/w two directories on the same computer.
You need to have BTSynce.exe in two different locations, with perhaps 2 different names, but the internal name seems to stop this working as two separate instances.
Firewall needs consideration too.
The settings.dat file lives in this directory:
"%APPDATA%\BitTorrent Sync"
I actually tried running multiple copies of BTSync.exe, but the second copy would not start. I was hoping to be able to set each copy with it's own port too.
-
I think ideally, the default mode for btsync would just prompt for a password to use with the WebUI, and generate (and reuse) a default config file stored in user's home directory.
Yes, I think a conf file should always be used, automatically, with one being generated the first time if it doesn't already exist. Then when you start btsync without specifying a config file, it will use the default one, but keep the option to use an alternate conf file.
-
Ability to connect (mount) a remotely shared folder:
127.0.0.1:8888?action=mount&secret=<secret>&locfolder=<local folder>
Ability to create a new share folder:
127.0.0.1:8888?action=newsync&secret=<secret>&locfolder=<local folder>
Code should be able to create folders on the fly if needed, perhaps a true/flase parametr
-
Did you start btsync with the config file command line option?
./btsync --config ./btsync.conf
I created a config file in a similar manner and it does ask for login details.
I also made the permissions on the conf file 600 and run as an ordinary user.
[Now Implemented!] Btsync As A Windows Service
in Feature Requests
Posted
Yes, I agree that via the task scheduler might be better.