email and password better than secret key

[Mimi]

I think the current secret key is OK, except that the secret key is stored in plain text.

Harold Feit closed the other thread with some nonesense. You cannot take my secret key (i.e. password) and store it in plain text, and now you tell me yadayada and close my thread.

Bittorrent Lab tells us the following:

"Can other BitTorrent users see my shared files?

No. BitTorrent Sync is based on the BitTorrent protocol, but all the traffic is encrypted using a private key derived from the shared secret. Your files can be viewed and received only by the people with whom you share your private secret.

What is a "secret" and how does it work?

A secret is a key that connects different devices and joins them together."

So if anyone with access to my private secret can view my files, then why is the secret stored in plaintext on my computer? Would you store UNIX (and perhaps Windows) password on disc in plaintext?

Bittorrent Lab, please do whatever, but don't have the client store the secret in plaintext!

[Disappointed Cat]

What's with the attitude? Like Harold said, if the settings file is readable by the attacker they'll probably also have access to the files that the app is syncing. Fine, maybe not write access which they could gain remotely with the secrets. Furthermore how would you secure the secrets without having to type in a passphrase at start? With something that's available without user interacton? Also useless... Security through obscurity is not a good road to go down on.

BTW, there are multiple solutions to this problem. On of them is disk encryption, another is file level encryption.

There's is no need to reinvent the wheel in every app.

[Mimi]

The attitude is the result of Harold's attitude! I didn't like his comment. And who is talking of reinventing the wheel? Disk encryption cannot solve this issue of storing sensitive data in plaintext. As soon as the disk is decrypted during boot up, then the file is no longer secure. Encrypting the sync.dat file could be a way forward, but this means Bittorrent Sync cannot access it.

It would be better if Bittorrent Sync add "salt" to the secret key before writing it to file.

[Disappointed Cat]

But why? You're not really protecting anything, once the attacker got in... A 'secret' isn't a password that you can match against a salted hash, it's needed in plain text. If you're worried about local users there are file permissions for that.

If offline security - disk encryption - is not good enough for you then you probably don't want to store those so sensitive files on your disk unencrypted and always mounted anyway.

[ChrisH]

Well, then simply don't let people you don't trust use your computer. I bet I can delete your user directory faster than you can copy my BTSync secret from the config file.

Physical access == you lost.

That said, I can't see why the settings.dat has to be binary and the (arguably more sensitive) sync.dat is at least mostly clear text.

[dswd]

Bittorrent Lab, please do whatever, but don't have the client store the secret in plaintext!

There simply is nothing you can do about that if you don't want to ask the user every time. If you store something on disk that lets you decrypt your files it also lets everyone else decrypt your files if they get hold of it.

Maybe we should grab the password when the user logs in and use that to decrypt the secret from disk and store it in memory as long as the user is logged in. But that requires some pam magic and needs to be done by an installation routine, so I guess the developers do not feel responsible for that.

[rdebath]

Maybe we should grab the password when the user logs in and use that to decrypt the secret from disk and store it in memory as long as the user is logged in. But that requires some pam magic and needs to be done by an installation routine, so I guess the developers do not feel responsible for that.

This magic is already available in the package ecryptfs-utils. This package allows a user to have a directory (or their entire home directory) encrypted and mounted (fuse filesystem) at logon. None of the files on the filesystem will be available if the user isn't logged in ... if the entire home is encrypted this, unfortunately, will also include the ".ssh" directory with it's "authorized_keys" file.