6

I'm building a Mac app that syncs the user's documents down from a third-party cloud service. When you set it up, it will sync all your documents down to the local hard disc, at which point you can access it in Finder.

For the purpose of this question, you can imagine I'm building a third-party Dropbox client. I'm not, but it's a good enough approximation for this question. The key points are that I don't control the cloud service, and that the data is accessed through Finder once synced down.

Suppose, at a later point, the server rejects the OAuth token / saved password, and the user is unable to supply a password that works. After a certain number of attempts or a certain amount of time passing, should I delete all the synced documents to prevent misuse?

Scenario 1: An attacker guesses a user's password, and uses that to log in to the cloud service through my app and accesses the user's documents. The user comes to know and changes his password/revokes auth tokens. At this point, the user would want his documents to be deleted from the attacker's hard disc. Or if the user sells / gives away / lends his laptop to someone, forgetting to log out in my app, and he realises it later and changes his password/revokes auth tokens, he would again want the already synced documents to be deleted from the laptop's hard disc.

Scenario 2: A hacker takes over the account and locks the user out. Or the cloud provider makes a mistake and locks the user out of his account. Then the user would want a backup of his data on his local hard disc, as opposed to losing access to his precious data.

If I delete all existing synced documents, I've failed the user in scenario 2. If I don't delete all synced data, I've failed the user in scenario 1.

Is there a best practice for this? A general guideline on what clients to cloud services should do if the user can no longer log in?

Note that I can't keep the data on the Mac's hard disc but deny access, since the user accesses the data through Finder, not through my app. The choices are to delete or not delete the data.

Kartick Vaddadi
  • 163
  • 4

3 Answers3

3

Scenario 1 will only work if the attacker is stupid. If a guy manages to steal the password of somebody and sync a cloud folder on his machine, the next thing he should do would be to save the content of the stolen data elsewhere just to make sure that a sync problem could not change it.

In that case erasing the synced folder will just have no effect...

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
2

You should keep user in control. That said, you can do the following:

  1. Never delete user synced files automatically
  2. You can delete synced files on user request, similarly like erasing data on the phone remotely.

This way user is in control of his files, and can remove files from other devices upon failed logout.

This would have to be a feature, like user in his control panel can see various devices / locations syncing his files, and he can then choose which locations / devices should erase backup upon failed login.

This gives user good control, that he can first update his password on all devices, and then request to delete from everywhere else, after his sync worked with new password.

In simplest scenario, it would not be good to delete the backup, because this leaves user in the dust and keeps him out of control.

Aria
  • 2,706
  • 11
  • 19
1

Rather than deleting the data, it's faster, more secure, and easier to just encrypt the local version of the data. The client never writes the decryption key to local harddisk, instead downloading it from the server each time it authenticates.

If the client gets disconnected from the server, they don't have access to the decryption key and it is effectively deleted. If the client reconnects, they can reauthenticate to retrieve the decryption key.

Additionally, you could tell the user to retain a backup key for decrypting in case the cloud service ever unilaterally disconnect or if a hacker disconnects the user.

The drawback to this is that the client had to be connected to the server at least once at program start up to retrieve the key, otherwise the user's folder remain inaccessible until either the user connects to the cloud server or until they input their backup key.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • This doesn't work, for multiple reasons: a) The app has to work offline b) Users will perceive encrypted files as corrupted when they try to open them. They will leave one-star reviews saying the app corrupts their data c) I don't want to bother the user with manually backing up keys. Too complex. The app should just work. – Kartick Vaddadi Dec 04 '16 at 03:52
  • @VaddadiKartick: a) If you really need offline capability, you can keep the backup key locally, symmetrically encrypted with the user's password. If the machine isn't connected to the internet, the program will ask for the user's password to decrypt the decryption key to allow access to the files, b) I'm talking about transparent encryption here, like full disk encryption or encrypting file system. User use their files as normal with normal software and your client software transparently encrypt/decrypt the files on the fly. – Lie Ryan Dec 04 '16 at 04:03
  • a) I don't want to prompt the user for their password each time the app starts. That would be a poor UX. b) The user accesses their files through Finder, as mentioned in the question, not through my app, so I have no opportunity to decrypt files. It boils down to either deleting the files or not. Which do you recommend? – Kartick Vaddadi Dec 04 '16 at 05:03
  • @VaddadiKartick: The user only need to enter password if they need to access the files offline. When online, the client can keep an access key that can be used to download the decryption key from the server. Yes, transparent encryption can be accessed by Finder just like normal files, all that the client software does is setup the mount, the OS then exposes the encrypted filesystem just like regular filesystem and redirects filesystem/block device calls under that mount to a FUSE/device driver code that encrypts/decrypts on the fly. Look into Truecrypt, FileVault, or EncFS. – Lie Ryan Dec 04 '16 at 06:18
  • @VaddadiKartick: Deleting files is too late. Even basic file backup/disk cloning/forensic system would be able to backup the files before your application can manage to start to delete them. – Lie Ryan Dec 04 '16 at 06:21
  • After setup, the app should never prompt the user again for any password. Encryption is too complex to implement. The options are to delete files, and to not delete them. Which of the two do you suggest? – Kartick Vaddadi Dec 04 '16 at 08:34
  • @VaddadiKartick: if the security posture of your software is that low, then I'd recommend against deleting. There's no point in deleting files after the fact, deleting files would just give a false impression of security. The user's files are not materially safer by you deleting them. It's better to present an honest UI that what happens if the device is stolen/hacked is the user's responsibility, and the user should implement their own measures like Full disk encryption if that is an issue for them, rather than lulling the user into a false sense of security. – Lie Ryan Dec 04 '16 at 10:55