Node js server that create, read, and update user data using TCP socket and AES encryption

I've written a Node js server that create, read, and update user data from a SQL server hosted in Azure. Clients connect to the server using a standard TCP socket, every message sent or received will be encrypted/decrypted using AES 256 CBC.

Communication protocol

TCP is used to create a simple communication mean without the over head of HTTP/HTTPS, and the client will try to persist that connection in order to eliminate the need to connect every time a message is sent. That will also give us the ability to know the number of connected players, and to be able to send messages from the server to all connected players.

Authentication

There are no authentication at the moment, anyone could connect to the server using telnet or any TCP based client. However any data sent will be decrypted if decryption or JSON parsing failed the connection will be closed. I am open for any suggestion in this area.

Message format

All messages exchanged between the server and client uses JSON format.
Messages sent from client to server are formatted as the following JSON message:

{
    "ID": 0 // a number indicating which function to call 
    "msg": "{
            // embedded JSON contains the data
            ..... 
            }"
}

Messages sent from server to client

• Number indicating if the operation was successful(1) or not(0).

Or

• JSON containing data about the player, if the operation was about fetching player data.

Message process

All JSON messages received are parsed asynchronously and messages sent to the client are stringifyied asynchronously to avoid Nodejs main loop blocking.

Server.js

```
/ Library to add date and time to any console.log /
require('log-timestamp');
/ Asynchronous JSON parse library /
var parseJSON = require('json-parse-async');
/ Asynchronous JSON stringify library /
var asyncJSON = require('async-json');
/ Keymetrics advance metrics /
var pmx = require('pmx').init({
http: false, /

The first concern with this type of question is why (is it not using
TLS/HTTPS)? A theoretical overhead doesn't matter at all when the
protocol is broken. E.g. the IV is constant when it should be randomised
on every message, but that's just an example for why reinventing it is
a bad idea.

Next, this is probably only working on the "good" path, if there's
fragmentation and the messages arrive in multiple pieces (like one-byte
pieces in the extreme case, but in general with a bad or congested
network connection) the decoding will just fail. The right way is to
keep updating your cipher object with more input till it has all been
consumed.

Next, the SQL injection. Right now, if someone gets hold of the single
shared key the database is compromised since the input (from the
network) isn't escaped. Libraries should have calls to deal with this.

StackExchange Code Review Q#145400, answer score: 2