Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Is using "security" command on MacOS a good idea? #136
Let me start by saying that I am new to the whole security world.
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.
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.
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?
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.
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?
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
Therefore I propose the following workaround:
Is this going to work for everyone?
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: