Should I use local storage in Electron for database config?

user_148496 0
Viewed 743

I have written an Electron app. It's working fine. I use local storage to save all the options that can be made in the app. That includes database configuration.

In a browser this is may a good idea because a website may be able to hack it?

This is not a website but an Electron app that does not load any webpages except for the main index html file.

Should I use local storage for database config?

So, should I use local storage for database config if I care about basic security? It's not a bank (hash not needed), but it should not be open to the world to get.

Except for the main questions, there are some optional subquestions around it.

  • If it's not a good idea, what should I use instead?
  • If it's not a good idea, how could it be hacked when I decide what goes into the html?
  • Local storage is not a file. Is there a chance the settings may be lost and gone?
electron local-storage security database
2 Answers

I assume following:

  1. You use a two tier architecture. Client written in Electron and a database.
  2. You put credentials to the database into the local storage operated by the Electron app.
  3. The database is storing non-public data, or other data that needs some kind of protection regarding integrity or confidentiality.
  4. The database and the schema are multi-tenant.

If what I claim above is true, then no, your solution is not secure. The solution you provide does not fall into the category of hardcoded secret, but is pretty close. In memory you may hold secrets that may give the user the same level of right he already has, like his session cookies or tokens. You are not allowed to put anything which - when obtained - would allow the user to have bigger access rights.

So, how to solve this. Simply said you can't. You might be tempted to obfuscate or hide or encrypt data, but obfuscation can be broken, hidden can be found and encrypted data must be decrypted with a key at some point that must be lying around somewhere.

Solution is rather a three tier architecture with an application server doing authentication, authorization and access control. Unless you want to play and give every user his own db schema/access rights in the database, which might be a solution too, but I don't know anyone who would be doing this.

user_8314600

As others have noted, you should definitely not put database connection secrets on the client. Secrets only stay secret if you can control its location. Living on a client machine is not a good spot for this and no amount of encryption will save you. Configure an application server with authentication and access control, and have the client communicate through this gate keeper before getting to the data layer.

user_19203260
Related