Maccy
Maccy copied to clipboard
p0deje
Encryption of clipboard
A lot of sensitives data are accidentally stored in my clipboard. A password encryption will be great !
Thanks for your work
I guess using AES-256 encryption encrypted data using keys generated from a main password, with a password-stretching algorithm like PBKDF2.
And the local master keys should be encrypted using AES-256 with a key derived from a local passcode using PBKDF2 if we want to quickly open Maccy.
This way, unencrypted data never touches the hard drive ?
I guess the passcode or the main password would be entered at Maccy startup ?
Like Bitwarden, Standardnotes ...
I am not experienced with encryption and it's quite new to me. I'm concerned about making it both usable and secure:
- If the password was entered at startup and the computer went to sleep after, should it ask for the password upon wakeup?
- What are the benefits over standard macOS disk encryption?
No Problem ! This is just an idea because I find this very important when I Copy/Paste some passwords or sensitives informations.
- Yes or no, maybe let the user choose?
- Only MacBookPro 2018 or later have disk encryption enabled by default with the T2 chip. For other Macs, many people do not enable FileFault for performance reasons or because it is not compatible with bootcamp or raid. So, encrypting the application is a kind of independence from Apple's encryption and an additional protection in case, after unlocking the mac encryption at startup, another program wants to access the clipboard's log
Thank you for your awesome work !
Another issue is that App Store has some rules about using encryption in software. For now I don't care about it, but as soon as encryption is used - there will be some additional process to follow for the App Store.
In any event, I've got no capacity to work on this at the moment so any help is appreciated.
Just a quick thought on this.
Encrypting the data before writing to disk would be nice to prevent other apps from reading.
From the user’s perspective it should be effortless. The key used for encryption/decryption can be stored in and retrieved from Keychain automatically.
A nice-to-have but not essential since Maccy already tries its best to ignore saving sensitive content.
I agree with the idea of implementing "transparent" data encryption. Maccy should generate a random key at first launch and store it in the keychain; then use it for encrypting/decrypting data stored in the database, with no user interaction (i.e. password prompt) at all.
Benefits would be:
- Protection of data at rest without having to assume that everyone has FileVault enabled.
- Same idea for backups. Time Machine backups in macOS Catalina and newer are immutable, so if you cmd+c sensitive data and forget to promptly delete it, it will be backed up and the only way to get rid of it will be to delete the whole backup(s) involved. Also, "orphan records" seem to be only cleared at launch, so deleting sensitive entries from Maccy may not immediately remove them from storage.
- Data protection against applications having full disk access (which, IMHO, is the most important).
I see Maccy uses Core Data for persistent storage, so I think you would need to do what is described here. Alternatively, you could move away from Core Data and directly use SQLite + SQLCipher for full database encryption.
"orphan records" seem to be only cleared at launch, so deleting sensitive entries from Maccy may not immediately remove them from storage.
Just to clarify, clearing at launch was just a measure to clean up after the bug, but now deleting entries should not leave orphaned records.
Just to clarify, clearing at launch was just a measure to clean up after the bug, but now deleting entries should not leave orphaned records.
Ah, that is weird. I'm on version 0.22.0 (9) and I still regularly find deleted entries in the ZHISTORYITEMCONTENT table (with the ZITEM column set to NULL). However, it does not happen all the times. Maybe it's a regression of #274? I'll share more info there if I find a pattern.
Ah, that is weird. I'm on version 0.22.0 (9) and I still regularly find deleted entries in the ZHISTORYITEMCONTENT table (with the ZITEM column set to NULL). However, it does not happen all the times. Maybe it's a regression of #274? I'll share more info there if I find a pattern.
The issue was fixed in #274 so if you still see it - it's definitely a bug, which needs to be fixed. Please share more details and I'll fix.
I am going to close this as working as expected. After reading https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations it looks like I'd have to provide some compliance documents for submitting to App Store. I don't have time or desire to deal with this so I'd rather leave it as-is, especially taking into account nobody is willing to provide a PR adding Core Data encryption.
Feel free to re-open if I'm wrong about compliance and miss something.
That's unfortunate, I hope that a future PR also provides some help with gathering/preparing/submitting the compliance stuff and you'll consider it.
