Application made in Electron Framework are insecure?

Question

I am a beginner with Electron, I have good amount of experience with HTML/javascript and window desktop application development(win-forms and WPF). I loved js/HTML5 so much that I wish someone could come up one day with a framework where I can write js/HTML5 to create desktop applications. And now Electron is here.

From what I have read, Atom is one awesome product made using Electron Framework. I heard its good because it is HACKABLE. OK! no problem! Does it mean a desktop application made using Electron framework are insecure, anyone can decode it and use it against the user of my application.

I am asking this because am going to start developing a desktop application and considering Electron an option to develop in.

Also, packaging of the application will run in all three platforms? iOS, Win and Linux? I know I have to take care of the modules I importwhich can be platform specific (for example 'auto-updater')

Answer 1

Security is a relative thing. Nothing is completely secure. The idea with security is to make it difficult enough to break through your security that it is hopefully not worth the time and effort it would take. This depends on how motivated the malicious person is which will usually depend on the type of information being processed or stored or the services being performed. You can compare it to putting a lock on your front door. Most locks are not very secure in that someone trained to pick/bypass them can typically do so very easily. But they prevent the average person from choosing to open your door just out of casual temptation or curiosity.

If the code for a program is properly written then even if a hacker can view the code, it should still be secure. If this were not true, all open source software would be insecure because others can see the code. However, if the nature of the application you are making is that it needs to be as secure as possible, then you can go a level beyond that, making it even more secure by trying to avoid people looking at the code, just in case that gave them ideas of how they could exploit it. If that is what you are going for, then it seems to me Electron is not your best option. People can view your code directly. Even if it is obfuscated, that still leaves them with JavaScript code, and as @Cenebyte321 pointed out, it can be "beautified" somewhat. Although a beautified version of properly obfuscated code would not be clean or readable code in terms of the concepts presented by it. It would not be anything close to the original. Otherwise, you could just take any working code, and make it readable and well organized just by running a beautifier on it. It is good to realize that technically you can decompile any executable back to source code. Even a binary program written in C can be turned back into C code. In that case, the "obfuscated" code produced would likely be even ore obscure, so there is some advantage to that. But still, it can be decompiled, and it should be valid C code. Hiding or obfuscating the code should never be relied upon for security. At best, it can create an extra layer of difficulty beyond your actual security. Alternatively, making your code open source and inviting people to audit your code and report vulnerabilities is also a good strategy.

Once malicious code is on a system, it is very hard to protect against it. The more important thing is to make sure that whatever servers the app is communicating with are secure (again, in the relative sense) and the API to them is secure. It should be secure enough that if someone looks at the source code of your app, and figures out how your server's API works, that is no problem for you. Any sensitive communication to a server should be encrypted. You don't want some admin username and password hanging around in the source code. But you don't want that with any app written in any language.

Ideally, any passwords saved on the user's computer should be transformed in some way before being saved (possibly salted in multiple ways and hashed, or whatever the cool kids are doing these days) so that if someone gains access to that data, they are only seeing a modified version of it. When this is done properly, there is not supposed to be a way to decrypt the passwords, although there are techniques people can use to try to produce a password that will result in the same hash. You should only compare the altered version of a normally entered password to the saved altered version of the actual password. The principals of safely storing passwords and having secure APIs and communications to a server are not specific to Electron, any language or framework you use will require the same careful thought about security.

Just in case my words were misleading, I was not implying it would be standard practice to locally store passwords used to access the server. Ideally, the user would have to type passwords of that nature each session, and it would never get stored locally. But for convenience some apps do allow you to locally store a password, so you don't have to type it in every time. Really, it depends on how sensitive the data accessed by those passwords is and how important convenience is to your users. A middle ground that is common is to not require the user to enter their password again every time, but this may not mean the password was actually stored locally.

But if malicious software is running on your user's computers, it could probably log their keystrokes anyway and discern usernames and passwords that way. Even encrypted communication is not foolproof, as security holes are eventually discovered in them, and newer protocols are developed. Sometimes governments or other people know about backdoors that were intentionally designed into a type of encryption. Just hope nobody else has found those backdoors yet, as they are essentially security flaws intentionally designed into the encryption protocols. As JavaScript tools become more advanced it is possible that obfuscated JavaScript code could be almost as obscure and confusing as obfuscated C code or perhaps there already are tools that accomplish this.

Answer 2

Yes, Off-course desktop application built with electron is less secure unless some guys like me indulge in debugging it. Recently yahoo messenger updated to new version with is a electron atom built. And recompiled it and changed the icons. recompiled yahoo messenger for my desired icons:

comparison of yahoo new and recompiled:

Answer 3

I suggest that if the application is information-sensitive or an enterprise application do it in another "traditional" framework. In Electron one can get the source code, modify it and even repackage it with very minimal effort since the plain JS files are available to anyone with the app. I know most people say "you can obfuscate it", but there are lots of online tools to "beautify" the code and get back something very identical. Also some of the "obfuscators" manage to actually break the code.

Answer 4

An Electron app is no less secure than any other application hosted on a person's computer. If a nefarious individual gains access to your computer it really doesn't matter if your application is in Electron, WPF, or any other technology. They can find a way to use the application against the user. Furthermore, most code can be reverse engineered and vulnerabilities exploited. I don't think you have to worry about this. If it were that insecure companies like GitHub (who makes it), Microsoft, and Slack would avoid it.

That being said, if you want to attempt to hide information from the user Electron source code is a little easier to view as it isn't in binary form. You can, for example, go into the app folder for Visual Studio Code which is built on Electron and view/manipulate the source code. I am not sure if the license allows it, but you can do it. There are ways you can mitigate this. You can obfuscate the JavaScript and put it into an ASAR among other things.

I am not sure I understand your final question fully. Electron does indeed run on Windows, Mac (OSX not iOS), and Linux. A package can be downloaded and executed on all three assuming you have the correct modules. As for installation, Squirrel seems to be a popular choice. You're going to need to massage things for each platform. Check out how Visual Studio Code does it for each platform and I would recommend following suit.