I installed a windows app that stores cookies in a plain text un-encrypted database. Is this a problem?

Question

I have recently installed an application that was developed with Electron that requires I authorize via Google to use the application.

I did this at the same time as monitoring the application with procmon and seeing what the application does. It appears to write to a SQLite3 database stored in AppData/Roaming on Windows.

The database is not encrypted or password protected but contains sensitive cookies such as .google.com NID xxxxxxx and HSID and LSID values.

This concerns me because I can use these values to make requests to Google which could be used to mimic my identity.

Edit

I took the values and I replicated a Google request by replaced the values in the database and I could successfully make a request to a Google service. In my example I used returned my recent Google activity in JSON form. After more testing I was also able to view my contacts and perform other actions.

I am not a Windows user or Windows developer but this strikes me as strange as this database is readable which means a rouge application/user could read this and the fact I can replicate requests worries me. Surely apps are supposed to use API's for this and not storing users cookies? Basically this app undermines the security of my Google service.

I know Chrome stores it's cookies in a SQLite database but there is at least some level encryption there because cookies are encryption. But, they're not for this applications database. My Brave browser's database for example is protected by SQLCipher.

Is this a security concern and if so what category does it fall under?

Answer 1

There are different approaches here.

First is why is the file not encrypted ?

On modern OS, applications often assume that security should be managed at a different level. What they want is to be able to store data somewhere and later read it back. At most, they ensure that files they create and that could contain sensitive data can only be accessed by the current user (or by administrative accounts).

The rationale behind that is that the user can always use encrypted partitions or folder if they want, and that the secret used to encrypt highly sensitive data should not be know to the app. If it was, it would just be obfuscation. The most that an application can do is to encrypt a file containing subsequent secrets and ask you for a master password each time you want to use it. But this is mainly used by applications that have to use subsequent secrets to access third party sites or applications

What seems much more weird to me is the stored data.

If the local application only stores a secret that identifies yourself to its server part, I see it as fine. The OS tells the application that the user has successfully identified themselves, and give access to the file containing a secret only relevant for the application. But if I have correctly understood your question, the stored cookies allow to impersonate you at Google level. That means that the application could use that to act on behalf of you for other purposes on other sites. IMHO this is a serious problem that should be reported to the publisher of the application.

Best practices would probably recommend not to use this application until the problem is fixed.

Answer 2

EDIT: Based on your comment, it sounds like your concern might be less "why are these secrets not encrypted?" and more "why is this app storing full Google session tokens instead of using OAuth to get restricted-access tokens?" That is a perfectly valid criticism of the software; it is highly unlikely that it needs more access than it could get through OAuth, and using OAuth is more secure because in the event that the token (or the app itself) gets compromised, it can do less harm to your account and it is easier to tell what happened and close off access.

Just don't expect the access token or refresh token to be stored encrypted, unless the app asks you for a password every time you launch it (and even then, it's possible for a malicious program to steal the tokens anyhow). There are some apps for which the extra security gained from demanding a password on every launch is worth the hassle (password manager apps/extensions like LastPass or encryption tools like gpg often do this, for example). Unless that's happening, anything else that is done to the secrets is basically obfuscation, not security.

---

The standard security model for Windows (and other modern general-purpose operating systems) assumes that any code you run is trusted to have whatever privileges you run it with. In other words, if you don't trust a program with access to your saved cookies (and all major browsers store cookies either in plain text or easily decryptable by a running program), then either run it in a sandbox that has limited access to the file system (such as a Windows Store app on Win8+, or the highly-restrictive sandbox Chrome uses for its renderer processes), run it under a different user (standard users cannot read the contents of another user's profile directory, including the AppData directory), or don't run it at all. "Full-trust" (non-sandboxed) apps running under the same user account do not, and cannot, keep secrets from one another; the burden is on the user to not run such full-trust software unless you do, in fact, trust it.

While it might give you some peace of mind if the cookies were encrypted, what encryption key would you use, and where would it be stored? You'd either need to enter a password to generate a key every time you launch the app, or the key would need to be stored in such a way that any other programs running under your account could also access the key and then access the files (there is no such thing as data that only one program could ever read). For that matter, if you run a malicious program under your account, it could simply attach to the Electron app as a debugger and read its secrets straight out of memory.

If you're concerned that somebody running software outside of your account - for example, a privileged process that can read into other users' home directories, or another operating system entirely (such as a thief might use to bypass Windows' protections and try to steal data from your hard disk), you could use encryption to defeat that. Windows offers three main ways to do this: DPAPI (Data Protection API), EFS (Encrypting File System) and BitLocker Full Volume Encryption. DPAPI encrypts or decrypts arbitrary blobs of data with a key that is protected by the user's password; a program must specifically request the data be encrypted or decrypted but doesn't have to supply a key because if the program is running under a logged-in Windows session, the user's key is used (if the program is not running under the user that encrypted the data, this won't work). EFS encrypts specific files (setting it for a directory encrypts all the files within that directory) also using a key protected by your Windows password, but transparently decrypts the data on read (and re-encrypts on write) for processes running under your account. So long as an attacker cannot guess / brute-force your password the data is safe, but malicious software that you run (or that an attacker runs after compromising a program you ran) can still read the data. BitLocker encrypts the entire hard disk (aside from a small bit containing some boot code to enable decrypting the rest) and can be set up to require a password when the computer boots to Windows, but once Windows is running, any software (not just software under your account) will be able to access the disk; BitLocker only protects against offline attacks.

---

EDIT 2: You mentioned Chrome's encryption of cookies. Chrome uses DPAPI (on Windows), which uses your password as a key protector much like EFS does. On OSX, it uses a password-derived key and stores the password in the Keychain, which I believe is also protected by the user's password (though I may be wrong). On Linux, Chrome apparently uses the static, hardcoded password "peanuts" to derive the encryption key. Security-wise, that last approach is worth exactly "peanuts", so at least the "password" is appropriate. Also added DPAPI to the main response.

Answer 3

Yes, this can be a security problem as plain text databases can easily be read by unauthorized individuals. Sensitive information such as login credentials, personal data, and other confidential information stored in the cookies can be compromised. It is recommended to store sensitive information in encrypted databases to ensure their security and privacy.