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

[jmfederico]

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]

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]

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]

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]

@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]

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]

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

[gilbertchen]

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]

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]

I just checked in https://github.com/gilbertchen/keyring/commit/8855f5632086e51468cd7ce91056f8da69687ef6.

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: https://github.com/gilbertchen/duplicacy/blob/923cd0aa63247fdee1c3b3b6eb166ca712e5e00a/src/duplicacy_keyring.go#L10 To:

        "github.com/tmc/keyring"

[gilbertchen]

This issue has been mentioned on Duplicacy Forum. There might be relevant details there:

https://forum.duplicacy.com/t/build-duplicacy-from-source/1091/1

[jmfederico]

Should this ticket be closed?