0

We're using node.js with express as a server gateway to AES256 individually encoded data. The data (and server code) are on a single server in a heavily locked room in our facility, accessible by hard wire ethernet only. Access points are dedicated hardwired devices. If someone were ever able to steal that server they could get access to the source code. They would have the keys and decoding algorithms to our encoded data.

What if we compiled the JavaScript node.js code and left only that on the server (instead of JavaScript source code)?

Does the compilation process offer enough security such that a motivated thief wouldn't be able to identify the encoding/decoding techniques that are in use to protect the stored encrypted data?

zipzit
  • 3,778
  • 4
  • 35
  • 63

2 Answers2

5

Does the compilation process offer enough security such that a motivated thief wouldn't be able to identify the encoding/decoding techniques that are in use to protect the stored encrypted data?

No.

First off, you don't say what you really mean by "compilation process". There is no process with Javascript that is analogous to compiling C++ into binary assembly code. Javascript is an interpreted language, not a compiled language. The Javascript interpreter may do a compile step internal to the JS engine, but that's not something you can do yourself. The node.js Javascript engine requires plain text legal Javascript as an input.

So, any compilation process you would run on your Javascript code would just be compacting and perhaps obscuring it. It's still plain text Javascript code. It's still runnable by anyone. Anyone can still diagnose what it does or how it works. Obscuring it (like replacing descriptive variable names with short one or two letter names) makes it a little more work to analyze the code and understand it, but it is only a temporary obstacle that can still be overcome by any determined hacker.

If someone were ever able to steal that server they could get access to the source code. They would have the keys and decoding algorithms to our encoded data.

You will need to physically secure access to your server and the code on that server in order to protect it and you will need to rely on that protection.

If you are using a packaging tool that creates a runnable .exe file, then keep in mind that that is not really compiling your Javascript. It's just packing it into a shell of a .exe so that the native code .exe can run, can extract your Javascript from within the .exe, can put that in a temp file on the hard disk and can then execute node.js passing it that Javascript source file. This is a packaging step, not a binary compilation step. Now, the package in the EXE may be binary compressed, but when the code is passed to node.exe it's still going to be plain text Javascript which can still be seen by a determined hacker.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • I was looking at things like [this](http://stackoverflow.com/questions/8173232/how-to-make-exe-files-from-a-node-js-app) and [this](https://github.com/nwjs/nw.js) . You nailed it exactly, I was thinking in C++. So an `.exe` is not always an `.exe`? – zipzit Feb 01 '17 at 19:35
  • 1
    @zipzit - You should have made your question about a specific tool like one of the two you just put in that comment. I answered your question generically since you provided no such specific direction in your question. And `.exe` is always an exe, but a tool that produces an exe that then ends up running node.js is still going to have to create plain text Javascript that it can pass to node.js and it's' even probably going to have to put it into a temporary file before running node.exe so the source code can still be grabbed out of a tool like this. – jfriend00 Feb 01 '17 at 19:39
  • @zipzit - I added more to my answer about `.exe` packaging tools. – jfriend00 Feb 01 '17 at 19:42
  • You know, I just realized I could write the entire server code in C++ or Java, and then compile that. It would be way ugly, but possible. Not sure that really improves security, but its a thought. And that really wasn't part of my original question. – zipzit Feb 03 '17 at 07:20
0

Your problem is not properly mitigated that way. No matter how many jumps you'd make a bad actor jump through, it's still all on one server no matter how opaque.

Look into solutions where decryption requires a key that is never saved to disk on that machine, instead securely retrieved each time your application (or better yet, your entire server) starts such as hard drive encryption programs that must succeed before the main operating system can even load.

JSmart523
  • 2,069
  • 1
  • 7
  • 17
  • I get that. The weak link is the number of secure storage rooms. If you have only one room, having data on different drives within that room are really the same as one drive within that room. Remember we're offline (to enhance security). – zipzit Feb 01 '17 at 19:32