email and password better than secret key

[tommyabc]

the secret key is difficult to transfer to another computer. you can't copy and paste. you need to send an email to yourself. why not use email and password to log in to establish a connection.

current process is too cumbersome.

dropbox only requires email and password.

usability is a major problem in the current process.

[deux]

Due to the nature of this application, it's probably not possible. First, it's decentralized, so there is no central place to "register" or "login". Second, it's not wise to generate secrets based on email and password as supplementary.

[GreatMarko]

why not use email and password to log in to establish a connection.

current process is too cumbersome.

dropbox only requires email and password.

"log in" to what?! I think you've perhaps misunderstood what Sync actually is; Unlike DropBox, there is no central server - BitTorrent Sync is completely de-centralized! Having no central server where your email address & password are stored makes Sync far more secure, and far more versatile, than DropBox!

[Swisstengu]

Just encrypt your mail containing the secret - GPG isn't there for nothing . It may as well be used on Android phone (with APG) in case you don't have a way to get the QRCode for the mobile app (there's also something for iOS I guess).

More over, as GreatMarko pointed it out, there's no "log in"-thing, secret is used in order to do crypto stuff on chunk content and as share folder name for btsync to know what we want.

[effem]

Greetings to all,

BTsync is really interesting.

The problem with using your username and password rather than secret key is not given the difficulty of use.

The problem, in my opinion, is that the password is not written anywhere and stays in people's heads.

The secret key instead is written in clear on your pc and this can lead to being stolen.

If a person physically takes possession of my computer for a few seconds can be seen in light of the secret key and send it anywhere.

We must, in some way, do not write anywhere the secret key and the display of the same must be done with an additional password.

At least as an additional feature for the truly paranoid

The key in plain sight (especially in Windows) is not safe.

Francesco

[btusername]

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.

[handle]

Greetings to all,

BTsync is really interesting.

The problem with using your username and password rather than secret key is not given the difficulty of use.

The problem, in my opinion, is that the password is not written anywhere and stays in people's heads.

The secret key instead is written in clear on your pc and this can lead to being stolen.

If a person physically takes possession of my computer for a few seconds can be seen in light of the secret key and send it anywhere.

We must, in some way, do not write anywhere the secret key and the display of the same must be done with an additional password.

At least as an additional feature for the truly paranoid

The key in plain sight (especially in Windows) is not safe.

Francesco

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. There are methods of utilizing a username and password in a decentralized fashion, however, that is secure. An example of such a protocol is SRP, or secure remote password protocol, which allows not only a server to authenticate a client via password, but the client can also authenticate the server with the same password. That being said, this is probably more trouble than it's worth, and a shared secret is perfectly fine to use in a distributed system.

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.

[Swisstengu]

Under Linux, you may as well create a dedicated btsync user, give the config-file to it only (chown btsync: <config> && chmod 0600 <config>), and ensure this btsync user has at least rights to write in the directories.

Meaning : either he owns some directory, or, if you want to sync some directories in your home, you'll have to add "btsync" to your usergroup, and ensure your umask is 002 as well as btsync process, and do a chmod 2775 <directory>.

This way, you will be able to add content to this directory as well as btsync user.

As previously said, there is no such thing as "login" in btsync process - only crypto. The secret key is not to be considered as a credential information, as it is a encryption key (or part of).

Just one other note:

if someone can physically access your computer, you're screwed, you can't do anything against that. You have to ensure nobody can log in your computer, or access the BIOS, or add stuff to it (physical keylogger for example) - at this extend, you'd better work in some bunker I guess .

The current system with the secret is good enough. It's people responsability to ensure it's not in the wild. This may as well be a good way to understand how leaks happen in real life, how people can get Root CA from, for example, Komodo .

Be safe, be sure of your environment - that's all.

Side node bis: if you really want something nice, just start some headless, daemonized virtual machine such as a KVM or xen instance, running the btsync stuff - only access should be through SSH, with some private, password-protected key. You can even encrypt the VM hard drive to prevent someone clone it and get its content .

Security can go really far. But, imho, it must be the user concern - BitTorrent team provided a good tool, we have to ensure our own security from now on .

Cheers,

C.

[btusername]

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.

[Swisstengu]

Greetings to all,

BTsync is really interesting.

The problem with using your username and password rather than secret key is not given the difficulty of use.

The problem, in my opinion, is that the password is not written anywhere and stays in people's heads.

The secret key instead is written in clear on your pc and this can lead to being stolen.

If a person physically takes possession of my computer for a few seconds can be seen in light of the secret key and send it anywhere.

We must, in some way, do not write anywhere the secret key and the display of the same must be done with an additional password.

At least as an additional feature for the truly paranoid

The key in plain sight (especially in Windows) is not safe.

Francesco

Just don't use Windows, if you're "truely paranoid" . </troll>

[btusername]

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.

[handle]

private and public keys.

Public key cryptography does not solve anything when the private key is also stored on the same machine. Alternatively, if each keypair is different per peer, then you can manually verify each peer that connects to your node, however this is terrible in terms of usability. It means for every one peer you add, due to the distributed nature you have to verify that peer on every single other node. When you add another peer, you have to do that again, with one more to verify, etc. Imagine having to do with when you have 200 or more peers syncing with each other.

[Swisstengu]

Public key cryptography does not solve anything when the private key is also stored on the same machine. Alternatively, if each keypair is different per peer, then you can manually verify each peer that connects to your node, however this is terrible in terms of usability. It means for every one peer you add, due to the distributed nature you have to verify that peer on every single other node. When you add another peer, you have to do that again, with one more to verify, etc. Imagine having to do with when you have 200 or more peers syncing with each other.

Oh, this is named SSH, isn't it ?

A fingerprint may be provided by the host, maybe… It may be a nice feature, but as you pointed out, it will be a hasle to validate them while having more than 6 devices…

[GreatMarko]

The problem with using your username and password rather than secret key is not given the difficulty of use.

The problem, in my opinion, is that the password is not written anywhere and stays in people's heads.

Hmmm... so which is safer? A secret in someone's head, or a password stored on a remote 3rd party server!!? ...I think the former! If you were to go down the username/email and password route, these details would need to be stored on a server somewhere - this is FAR less secure than the current method of "secrets"!

[handle]

Oh, this is named SSH, isn't it ?

A fingerprint may be provided by the host, maybe… It may be a nice feature, but as you pointed out, it will be a hasle to validate them while having more than 6 devices…

SSH is not comparable to bittorrent sync. SSH usually has multiple clients connecting to a single server. Each client verifies that the server has the correct key, and the server authenticates the client via a password so no key verification is needed on that side. So if you have one server and 6 clients, you verify 6 times. If you add one more client, you verify one more time, if you add another client on top of that, you only verify once again, etc.

With BTSync, on the other hand, every peer connects to every other peer. That means if you have 6 nodes, you verify 6 times. If you add one more node, you verify 7 more times. If you add one more node, you verify 8 more times, etc.

[Swisstengu]

Yep, true. Was more speaking of SSH for the key exchange .

[handle]

Hmmm... so which is safer? A secret in someone's head, or a password stored on a remote 3rd party server!!? ...I think the former! If you were to go down the username/email and password route, these details would need to be stored on a server somewhere - this is FAR less secure than the current method of "secrets"!

First off, the secret is on disk and not necessarily in one's head. Secondly, a password would not be stored in plain text on a remote third party server - it would most likely be hashed, or hopefully stretched (think PBKDF2). Extra points if the hashing or stretching is done client-side.

The problem that comes from using a centralized server to authenticate is that you effectively give that server authority, meaning they can authenticate themselves and access all of your information. It also becomes a central point of failure - if this were the way things worked and Bittorrent Inc. decided to close their doors, Bittorrent Sync would stop working completely. The way they actually work right now (which in my opinion is the right way), is that even if the company shut down, the current version of Sync would still work without problems.

[effem]

Just don't use Windows, if you're "truely paranoid" . </troll>

I use only linux, and the problem I see much less noticeable!

As you said, I can run with a user btsync ad hoc and block the permissions so much stronger than you could do a "simple" windows user.

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.

Maybe you did not understand: I really like the idea of secret keys!

But I think it is much harder to find a decryption key in the process memory rather than reading the key in a file, especially if the majority of people who use windows put the keys in the same position!

By the way, you can change the directory location .sync as in linux?

Thanks,

Francesco

[handle]

I use only linux, and the problem I see much less noticeable!

As you said, I can run with a user btsync ad hoc and block the permissions so much stronger than you could do a "simple" windows user.

Maybe you did not understand: I really like the idea of secret keys!

But I think it is much harder to find a decryption key in the process memory rather than reading the key in a file, especially if the majority of people who use windows put the keys in the same position!

By the way, you can change the directory location .sync as in linux?

Thanks,

Francesco

That's fair enough. You should be able to use a symlink (junction in windows) to change the directory location, however that would not accomplish anything in this case. The best way to solve this would be to allow someone to encrypt their secret with a password, and require that password to be entered on startup.

[effem]

The best way to solve this would be to allow someone to encrypt their secret with a password, and require that password to be entered on startup.

Also in my opinion, you could leave the choice to the user.

Those who wish may decide to enter a password to encrypt the departure of btsync (client side) their secret keys.

The same password can be requested at the time of display of the keys in the GUI.

So, in windows, there is the possibility to set a config file to change the directory location .sync?

Francesco

[handle]

Also in my opinion, you could leave the choice to the user.

Those who wish may decide to enter a password to encrypt the departure of btsync (client side) their secret keys.

The same password can be requested at the time of display of the keys in the GUI.

So, in windows, there is the possibility to set a config file to change the directory location .sync?

Francesco

Indeed, hence why I said "allow". The "require" is only if they chose to do so.

It is possible to change the directory location with a tool called mklink, however it won't accomplish much because it'll still be on your drive, and whether the path is in the symlink or the config, it'll still be easy to find.

[effem]

Ok,

thanks

Francesco

[Datapotomus]

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==

[btusername]

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.

http://www.opinionatedgeek.com/dotnet/tools/base64decode/

[Swisstengu]

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.

http://www.opinionat...s/base64decode/

Sure - but the point is: "Yes, we can!" actually use some custom credentials (provided they are unique - i.e. not used for our private mail account, and so on ).

Won't be less secure though provide some nice way to remember the string.