btusername
-
Posts
34 -
Joined
-
Last visited
-
Days Won
1
Posts posted by btusername
-
-
Chris is spot on.
-
please keep in mind that your keys, no matter how they are generated, how long they are, or how random, are not secure in any way if you send them via insecure methods like
unencrypted email
chat
facebook, aol, yahoo
this includes all communications that are "secured" with SSL unless they are using DHE or some form of PFS (perfect forward secrecy).
This is because, the ssl keys are being handed over due to gag orders and wire taps required by the NSA and government.
This is also thought to not be only obtainable by the NSA due to speculation that is off topic. But in short, your keys and data are only as secure as your weakest link, and that would be at this point sharing the keys to sync, the storing of those keys, etc.
Some one earlier mentioned using GPG/PGP to encrypt the keys I believe. I would ask, if your going to take the time and effort to encrypt the keys, why not just encrypt whatever it is your sharing, and sync it with other methods.
-
BitTorrent Sync isn't open source, and there are, to my knowledge, no plans to make it open source.
The tracker URL is hardcoded into the software, so can't easily be changed. Also, even if you could change it, I don't think it's just a regular standard .torrent tracker, it's a tracker specifically designed/adapted for Sync, and like the Sync application itself, the Sync tracker code also isn't open source... so even if you could change the tracker url (which could potentially be done through modifying the "hosts" file on Windows for example), it's not going to do you much good!
As I say, my hunch is that as and when "Sync for business" emerges, this may well allow you to run your own "private" Sync tracker on your own infrastructure... in the meantime, your best option would be to use the "predefined hosts" options if you wish to avoid the relay/tracker servers provided by BitTorrent! ...and/or use a VPN service to make your various peers "all over the world" appear to Sync as being on the same local network, thus negating the need for a relay/tracker server altogether!
since the source insn't open, we cant trust what the application claims to due and is therefor insecure.
if, however, the sync protocol is opened up for the public (not just internal developers), than an open source alternative could be created and modified to preform other functions as desired.
-
I think the more important, and accurate question to ask is;
1. How does BT plan to monetize their heavy investment of BT Sync.
....
any guesses
-
This is probably one of the most parroted things I've heard in recent history. Just because something is free does not mean you are the product.
It indeed sucks that this is not released as open source, but that's most likely because this is built off a uTorrent codebase, which likely has proprietary portions they are not allowed to release.
I'm not discounting the possibility that you may be the product in this case, however jumping to it immediately without considering anything else is plain conspiracy talk.
to assume we aren't the product would be a leap also. We just don't know, that's the problem.
just to confirm no official announcement has been made on syncs licensing right?
-
You can make the exact same argument 20 more times but it's not going to make it any more correct.
i'll at least ponder the notion, maybe you are correct.
This however, is a good idea.
I agree.
-
If the option is to use GPG/PGP, or some form of encrypted chat to send the keys to be shared, wouldn't / shouldn't I just use GPG to encrypt the file im trying to share anyways, at which point i could use any syncing / sharing service.
To sync with someone else requires that you share your key, and if you cant share that key securely .. then you can't sync securely.
To say sharing your key is outside of Bt Syncs scope is to say that sharing your key so that you can Sync securely it outside of BT's scope and defeats it purpose.
BT doesn't have to even develop a secure way to share keys or communicate, just implement already existing features, team up with up and coming services like heml.is, or at least inform users that your security is dependent on the secrecy of that key, and that sending keys via unencrypted chat or email like facebook, yahoo, aim, aol, gmail, google hangout, outlook, etc is insecure.
-
Exactly.
Not to mention that you could easily just share a key by writing it down on a piece of paper, then it's completely off any network.
there is a million and one ways the key could be obtained prior to me being able to "write it down" (which is very inconvenient) and there is no way for me to confirm that this doesn't occur without the source being open.
-
Your exactly right, and it's already happening.
In a statement, Microsoft said: "When we upgrade or update products we aren't absolved from the need to comply with existing or future lawful demands.IE: backdoors to your data
http://www.guardian....ation-user-data
Microsoft has collaborated closely with US intelligence services to allow users' communications to be intercepted, including helping the National Security Agency to circumvent the company's own encryption, according to top-secret documents obtained by the Guardian. The documents show that:
• Microsoft helped the NSA to circumvent its encryption to address concerns that the agency would be unable to intercept web chats on the new Outlook.com portal;
• The agency already had pre-encryption stage access to email on Outlook.com, including Hotmail;
-
To go back to tommyabc's point you actually can use a username+password combination as long as your password and/or email is long enough. Just plug it into a base 64 converter. You can get one at sourceforge like the following. http://sourceforge.net/projects/gbm64/
You can just pop a string like the one below into the text field:
myname@email.com/password123
It will spit out a base 64 encoded string.
bXluYW1lQGVtYWlsLmNvbS9wYXNzd29yZDEyMw==
wouldn't really be wise as if someone finds your secret key, they could easily decode the base 64 and get your email address and password.
-
-
thats like saying linksys, belkin, or asus only has to develop a router to transfer your data, not secure it by using some fancy wpa2 encryption.
do they need to develop new ways to communicate securely? No, but they could.
should they implement already existing features to secure your data and the applications reputation? of course they should.
This application is built around one single premise, sharing your key. Your advocating that the most important aspect of this application is not the burden of the application and protocol developers?
-
is the TOS, EULA, and PP for sync the same as those listed for the main BT projects?
http://www.bittorrent.com/legal/terms-of-use
http://www.bittorrent.com/legal/eula
http://www.bittorrent.com/legal/privacy
These listed don't yet mention the Sync product.
-
when you are required to share your key to sync data, it becomes the burden of the application to offer ways to share that key securely. This is undoubtedly the weakest link.
one time keys are not suitable for all syncing needs
I disagree, as this is a problem that has been solved numerous times over.
solved, yet not implemented in this application.
-
im referring to using ssl strip on the communication method, not bt sync itself. IE you send your key via some messenger service. Yes, im aware of HSTS. A secure method to share keys is needed, is the point.
-
The complaint about plaintext keys on disk is a valid one, however it is impossible to hide it from people unless you encrypt it. To encrypt it properly, you need a key that is also not on disk, i.e. you'd have to enter it in every time you start Bittorrent Sync. Once that's done, the key can still be found in the program's memory, and this is absolutely impossible to change, since having the key in memory is needed for bittorrent sync to work at all.
private and public keys.
-
There are several things that can be said about this idea in general. First, many people are thinking of "email and password" as in signing up to a centralized place and logging in there. This is a terrible idea because it allows that centralized place to access your data at any point in time.
I agree.
-
Not sure if this has been suggested previously, but a way to blacklist a client would be good, or cycle keys, or something....
Use case: my laptop is stolen. I need a way to cycle the key, or kick the laptop out of the sync group, preferably without manually deleting the sync folder on every device and setting everything up again.
more importantly, what occurs to that data when the device is lost/stolen and can you control it remotely?
Encrypted storage, remote data deletion etc.
You could have been syncing your other secret keys, your bank details, login cred's, scanned mail, resume with mailing address and phone number .... deleting that data may be very helpful.
-
Please add an option to store the configuration files in a custom folder. The fact that settings - and thus the secrets! - are stored in %APPDATA% (on Windows) is a huge security problem.
My laptop has an SSD and thus I can't encrypt the system folder with TrueCrypt. For similar reason, my home-built NAS system has a non-encrypted system drive. If someone were to get their hands on those systems (however unlikely), they would not get data straight away - all data drives are TrueCrypt'ed - but they would get my secrets. This could be solved by allowing users to move the settings folder to a custom location, which could then be encrypted.
im a little concerned with data storage on mobile devices, and the limitations of flash memory. It's not secure for the same reasons you point out.
-
Secure data deletion
would be nice to have built in secure data deletion for desktop platforms, not including mobile devices due to the limitations of flash memory, Wear-Leveling etc.
-
the benefit to not having user accounts and "login's" is that if your data is requested by someone from some server, or its found on a confiscated device and the authorities demand BT to hand over information pertaining to that user ... they cant because there is no user accounts.
"Hopefully" BT has setup the relays and trackers to retain NO data, and that the trackers cannot be setup to log transactions to create a traceable log of ones activity's.
creating a user account and logging in creates a trail of your digital footprint, by not having this .... this is a great feature.
-
The immediate solution is for users to only share keys via trusted channels, PGP encrypted email, possibly Heml.is, OTR, etc ...
but one has to ask oneself. When building the platform for BT sync, since we are only using one key here and your data is only as safe as the weakest link why wasn't some secure method created to share the keys in the first place?
PGP and GPG encryption for email communications is great, if you know how to use it and can discipline yourself to use it each and every time.
forget mining secret keys .... an attacker could setup an ssl strip MITN and collect secret keys shared via insecure communication channels.
-
I simply want to purpose the discussion around the recent revelations of NSA spying techniques, and how this effects the security of our sacred "Secret Key".
assuming the keys are shared via unencrypted email, skype, facebook, aol, yahoo, etc etc .... then our keys are no longer really "Secret" to say the least. This doesn't even begin to cover malware, keyloggers, etc.
This leaves our data at the hands of the government, their contractors, and anyone who obtains this information (attackers) ......
Now that Sync is in beta, is it to late?
-
actually a perfect example is with the recent revilations of the NSA leaks.
to share/sync, you have to know and hand out your "secret". If your sending that secret key over facebook, aim, yahoo, etc... theres a good chance big brother has it and will use it.
the lock/unlock feature wouldnt really help here as if you are handing out your secret key, there is a good chance you are giving it to someone else to sync with and the folder/file will be unlocked at that time.
Heck M$ follows all links sent via skype. It would be failry easy for them to implement a simular feature to log and sync any secret key sent.
Solution? Send your keys via email using PGP/GPG encryption, or maybe depending on the security and outcome of the new messenger service Heml.is ... or a deaddrop
I apologize ahead of time -- Can the dev's stop being assholes and release the crypto/architectural documentation please?
in Sync General Discussion
Posted
+1
couldnt say it any better myself. I cant recommend this product to anyone until the security claims are validated