Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is using "security" command on MacOS a good idea? #136

Open
jmfederico opened this issue Aug 28, 2017 · 9 comments

Comments

@jmfederico
Copy link

commented Aug 28, 2017

Let me start by saying that I am new to the whole security world.
I was a happy CrashPlan customer, but since they are closing their home plan, I (as many others) are in the search for a new alternative, and this is by far the best backup tool I've seen so far, honestly.

Having said that, there is one thing that worries me, maybe it shouldn't, but I rather ask.

I know that Duplicacy uses the "security" command on MacOS to access the user's keychain, and if I understand how MacOS ACL works, once I authorize "security" to access the passwords created for Duplicacy, any script that invokes the "security" command will have access to the information.

Is that correct?

If so, that seems like a bad idea.
If not, can you please explain how is my logic flawed?

Thanks

@nikjft

This comment has been minimized.

Copy link

commented Aug 28, 2017

Nope, you're right, @jmfederico. Running "security" at the command line will pull out all of your Duplicacy credentials. Worth pointing out that I already have a token file for hubic sitting on my HDD too (restricted access by file permissions, but...).

This is still better than many alternatives, as the "security" utility will only retrieve those passwords if the keychain is unlocked and the user's logged-in. So you lose your computer's login credentials to a bad guy, and they can pwn your backups. Short of that, or a malicious script that runs while you're logged-in, your credentials are safe. But at a minimum, Duplicacy itself should be the program authorized to access the keys and not the generic "security" utility.

A better way to handle this would be through public-key-encryption, so that the encryption key doesn't need to be protected for backup purposes, and the private key can be encrypted and password-protected until you need to restore files. This is how CrashPlan, Backblaze and most similar utilities manage security.

Glad to see people digging into the source on this backup utility as we all run around screaming following CrashPlanApocalypse.

@jmfederico

This comment has been minimized.

Copy link
Author

commented Aug 28, 2017

What worries me is not only the encryption key, but also the credentials to my cloud accounts.

If for some reason those were made available, a script could delete all my backups. That is what actually freaks me out.

How can Duplicacy be the app the requests access to the KeyChain?

Also, I didn't check the windows inplementation, don't know how that works, but I'm guessing is similar?

@gilbertchen

This comment has been minimized.

Copy link
Owner

commented Aug 28, 2017

I agree this is a security flaw. Duplicacy should call the KeyChain API directly instead of relying on 'security' to access the passwords.

On Windows it is even less secure than KeyChain. The passwords are encrypted by the Windows Crypt API, and then the encrypted passwords are saved in a json file under the .duplicacy folder. It is possible for a third-party program to decrypt the passwords stored there using the same API, but I can't think of a better alternative.

@nikjft

This comment has been minimized.

Copy link

commented Aug 28, 2017

@gilbertchen Public/private-key encryption? You can password-protect the private key and leave the public key in the clear. As far as I can suss out, most of the cloud backup programs do exactly that thing.

@jmfederico

This comment has been minimized.

Copy link
Author

commented Aug 28, 2017

Public/private-key encryption solves the encryption part for the backups, but cloud credentials still need to be stored in the machine and need to be accessible by Duplicacy.

On MacOS using direct access to the keychain solves that issue, but a solution for Windows is needed.

Any possible timeframe for direct access to Keychain?

@gilbertchen

This comment has been minimized.

Copy link
Owner

commented Aug 30, 2017

It should be done by the end of next week at the latest.

@gilbertchen

This comment has been minimized.

Copy link
Owner

commented Sep 14, 2017

Duplicacy uses my fork of github.com/tmc/keyring to access KeyChain on macOS. There is another form that has already implemented direct KeyChain access: https://github.com/SpiderOak/keyring/blob/master/keyring_darwin_arm64.go

However, XCode is required to compile that code. There doesn't seem to be a good way to build from source without XCode installed or cross-build on a different platform. Go 1.7 supports binary-only-packages which, unfortunately, isn't compatible with the go get command.

Therefore I propose the following workaround:

  • The direct access version will be named keychain.go
  • If you don't have XCode installed or you're cross-building Duplicacy, you will get the the version that depends on security
  • To enable direct KeyChain access, copy gitbhub.com/gilbertchen/keyring/keychain.go to overwrite gitbhub.com/gilbertchen/keyring/keychain_darwin.go, have XCode installed, and run go build duplicacy/duplicacy_main.go under github.com/gilbertchen/dupicacy

Is this going to work for everyone?

@jmfederico

This comment has been minimized.

Copy link
Author

commented Sep 14, 2017

Is it possible to make it use the keychain access by default, and to make it so that one has to copy the non-keychain one over insted?

This so that the default is more secure.

@gilbertchen

This comment has been minimized.

Copy link
Owner

commented Sep 23, 2017

I just checked in gilbertchen/keyring@8855f56.

Now if you want to build Duplicacy from source on macOS it will use the direct keychain access by default. However, you need to have XCode installed. If you don't want to install XCode, you can modify this line:

"github.com/gilbertchen/keyring"

To:

        "github.com/tmc/keyring"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.