CODEWITHSUNDEEP
databasesecurityelectronlocal-storage
Jens Törnell
Jens Törnell

Reputation: 24768

Should I use local storage in Electron for database config?

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.

Upvotes: 4

Views: 1548

Answers (2)

Splitty
Splitty

Reputation: 637

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.

Upvotes: 2

Marek Puchalski
Marek Puchalski

Reputation: 3659

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.

Upvotes: 2

Related Questions