node.jssecurityelectroncredentials

is electron's `safeStorage` for passwords and login credentials?


I need to store login credentials with electron js because it doesnt save them like all browsers. I have seen a lot of questions like this, but I never found a solution. I have seen in the electron docs about the safeStorage feature. is the it safe enough/good enough to store login credentials on the client side? if not what other tools are available to do that? I have heard about keytar but is it good?


Solution

  • The safeStorage api in electron exposes OS-level encryption/decryption using current user's secret key - please refer to electron source and chromium's os_crypt. On windows it utilizes DPAPI while on *nixes it uses whatever password manager the OS has as the documentation suggested.

    is the it safe enough/good enough to store login credentials on the client side?

    Depends, you should define "secure" first.

    Ask yourself, should the same user allowed to read whatever value inside the encrypted text? A tech-literate person may have the know-how to decrypt things you store using that API you are out of luck. See this QA for further discussion.

    if not what other tools are available to do that?

    There are a lot of tools (and encryption algorithm) to encrypt stuff in nodejs. However, you have to remember an encryption require you to have a key of some sort and the key need to be protected too. Hence, try your best to avoid "chicken and egg" problem regarding your key of keys.

    OS-based key storage avoids the key of keys problem by storing the "master key" in a way that only accessible using its API. At runtime, you can't retrieve the key at all, you just send a set of bytes for the OS to magically encrypt/decrypt. While at rest, the OS may rely on secure storage such as TPM (Trusted Platform Module).

    is electron's safeStorage for passwords and login credentials?

    Depends, if you are running a web service it is preferrable to not doing so. You should never dump end user's user name/password directly on a storage that you can't guarantee its security by yourself (e.g. your server). You should, put an identifier which can be revoked or may expire at later date - token or cookies.

    Imagine the trouble when your end user device get stolen. If it's a token/cookie, they can request you to revoke their access token bound to the device - the "Log me out from all other device."

    However, if its an in-situ application that authenticates to itself then its a fair game - though keep in mind about the first point. Its all down to your security model.

    Tl;dr : Its a wrapper for Windows Credentials, Libsecret, and Keychain as seen on the sources.

    It basically do what safeStorage already do - relying on the platform to store stuff. Thats why it depends on the threat of who will be stealing the password.