p0deje / Maccy

Lightweight clipboard manager for macOS
https://maccy.app
MIT License
12.5k stars 531 forks source link

Encryption of clipboard #151

Closed mrtpcet closed 1 year ago

mrtpcet commented 4 years ago

A lot of sensitives data are accidentally stored in my clipboard. A password encryption will be great !

Thanks for your work

p0deje commented 4 years ago

How would that work? When exactly the password should be asked?

mrtpcet commented 4 years ago

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 ...

p0deje commented 4 years ago

I am not experienced with encryption and it's quite new to me. I'm concerned about making it both usable and secure:

  1. If the password was entered at startup and the computer went to sleep after, should it ask for the password upon wakeup?
  2. What are the benefits over standard macOS disk encryption?
mrtpcet commented 4 years ago

No Problem ! This is just an idea because I find this very important when I Copy/Paste some passwords or sensitives informations.

  1. Yes or no, maybe let the user choose?
  2. 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 !

p0deje commented 3 years ago

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.

aluxian commented 2 years ago

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.

jacopo-j commented 2 years ago

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:

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.

p0deje commented 2 years ago

"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.

jacopo-j commented 2 years ago

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.

p0deje commented 2 years ago

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.

p0deje commented 1 year ago

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.

TryTryAgain commented 1 year ago

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.