Search the Community
Showing results for tags 'secrets'.
Found 4 results
Hi, I love the project of a bitTorrent sync program and have tested it for a couple of days. My main concern is in regards of security. Perhaps I do not understand "all as of yet" or perhaps I have some valid points. Anyhow thanks for enlighting me if needed :-) Today on iOS you can´t make your own unique secret if you want to backup your images. The secret are then predefined based on 33 characters. If I then add this to my computer it of course works but what stops other users from adding random 33 character strings? I mean as of now the chance is slim to finding anything but as users grow without a secondary secret there is a big security issue here (or isn´t it?) The big question is: Can anybody add my secret or is it just on that one remote computer? If anybody can add this secret the only way to "see" if people are sniffing (syncing) is to check your device list I guess? This could all be super safe if there was added a username alias to the secret. Then you would have it safer than any username / password system on the net. However when there is only 1 phrase and when the phrase is as short as 33 characters I agree that its impossible to "find targeted people" in this system but it would be rather simple to just make a script adding random "secrets" checking if a sync starts and then like phising "you see what you get" like other peoples "photos".. My other point is that you can set VERY large secrets on the Mac / Windows clients for full shares but "read only" is left always as 215 characters. Then it doesn´t matter if you want a supersafe share increasing the "secret" to 512 characters because the read only is always based on 215 characters.. So in other words as long as you dont open for "your own secret" also on read only then the "make your own secret" on full shares have no potential "enhanced security value".. I know lots of answer will debate how strong an encryption is but usually encryptions will be super strong if you add two dimensions to the encryption like username + password. Besides when I can´t change the read only password (Mac) then I have to rely on the algorithm made of the makers of the bitTorrent sync client while I tend to use my own algorithms.. I ask this because I see A LOT of potential in the app and hope to have a good forum chat in regards of security. Tried to search for this before I posted so I hope I do not repeat to many answered questions here.. Thanks! In simpler words: Secrets would work great if when someone adds a secret the hosting party are "alerted" with a "This user wants to add this folder - Do you allow this as the hosting party?".. Then the only thing that can happen is like on Skype where you sometimes get random users sending 1 message where you have to "block them".. So to have userName in the app would be a smart move anyhow I guess..
So, I create a read only share. I save the "secret" to a file where I can look it up later... My computer crashes. I want to rehost the same share - with the same secret so all my family members don't have to re-enter the secret (because many aren't technical and can't). If I put in the same secret I saved earlier, I'll just be read only to the share! Is there a way to preserve this information so I could rehost this share/secret? Thanks, Russell
Hi. I am really enjoying this service and am intending on using it with a small home server as a my own private unlimited dropbox service. I am a bit concerned about the secrets though. Maybe I understand them incorrectly, but it seems as though all you need to access someone's information is their secret, no secondary authentication token. For example, if the secret was the identifier or index linking you to the host then I would expect a second authentication step like a password or even something like an ssh key. Just have some way to limit the people who can access my data, other than whether or not they happen to stumble across my secret. Does that make sense or am I missing something? I realise that it could make the distributed aspect of the system tricky, with each client becoming a new host that then becomes responsible for authenticating, but a distributed whitelist or master password could solve this? Cheers SnakeJayd