Fairly straightforward request. It would be nice if the OAuth token that allows access full access to my Google Drive was always encrypted at rest. This would simply require a prompt for a decryption password at every start. Bonus points if long-lived tokens aren’t stored unencrypted in RAM for long either.
I see, this is interesting. I’ll bring this up to our engineers. So you want some sort of encryption integrated whenever you restart your Insync app?
So you want some sort of encryption integrated whenever you restart your Insync app?
I’m not sure your summary actually aligns with what I mean. Let me try to break it down to be more clear. Insync uses an authentication protocol known as OAuth. Google issues an OAuth token to the inSync app which allows inSync to access my files. Naturally that token is highly sensitive, it’s better than my Google password because it also bypasses the need for 2FA to access my Google Drive.
Now, the concern is that inSync stores that token on disk. Entirely unprotected as far as I can tell, it’s simply a field in a sqlite database file. Any software on my computer can access that file and dump that highly sensitive token and use it to access my Google Drive. It could be malicious software, or maybe backup software that stores a copy somewhere else that could be compromised.
My request is that the token by encrypted when stored on disk (aka in the database). This means inSync would prompt me for a password to encrypt the token with, and every time inSync opens it would naturally have to prompt me for that password again (to be able to decrypt the token and use it).
To skirt some of the technical details, there is more than 1 type of token used with OAuth, but on the long-lived refresh token is the highly sensitive one. It would be ideal if, on top of being encrypted on disk as described above, if it was also not stored in memory unencrypted except when necessary to get a new token. This would help mitigate risk from attacks that can dump RAM without necessarily having local code execution on the machine (see the RAMBleed Rowhammer attack for example).
Please let me know if I’m still not explaining myself well 
1 Like
All good! Thank you so much for making this detailed. We’re going to check if this is something we can do as you have a really good point on security on this feature request.