I've been working with Node.js for quite a long time. So, believe me when I say there's a library called `eslint-plugin-security` to detect common mistakes and security flaws you make while you're coding. Before discussing timing attacks on node.js, let's start by talking about my Eslint configuration on Socketkit's new privacy & security-oriented tracking API.

With the release of Node 15, I started converting the API to modules and added/improved my usual stack by adding more and more Eslint rulesets to make my code more persistent for outsiders. (if that day comes)

Here's my `.eslintrc` configuration for Socketkit's new Tracking API

~~~json
{
  "extends": [
    "plugin:prettier/recommended",
    "plugin:import/errors",
    "plugin:import/warnings",
    "plugin:security/recommended"
  ],
  "plugins": ["prettier", "import", "security"],
  "parserOptions": {
    "sourceType": "module",
    "ecmaFeatures": {
      "modules": true
    },
    "ecmaVersion": 2020
  },
  "env": {
    "node": true,
    "es6": true
  },
  "rules": {
    "import/extensions": ["error", "always", { "ignorePackages": true }]
  }
}
~~~

I was in the middle of writing an endpoint for update password action for users of our web page. I didn't want to take the usual approach and use Ory Kratos' redirection loop based authentication flow and convert our browser based forget password flow to node.js based API flow recommended by Ory Kratos. Since our API was based on fastify, we handled our day to day validations using the presupported, awesome library called `ajv`.

Here's an example schema by ajv and fastify, which checks for the type of 2 parameters: `password` and `password_again` and the existence of it using the required parameter from ajv.

~~~javascript
  schema: {
    body: {
      type: 'object',
      properties: {
        password: { type: 'string' },
        password_again: { type: 'string' },
      },
      required: ['password', 'password_again'],
    },
    response: {
      200: {
        type: 'object',
        properties: {
          state: { type: 'boolean' },
        },
      },
    },
  },
}
~~~

Since, password and password_again should be equal in order to make sure the user didn't want to change their password to a faulty one, we had to make sure that both of them is equal to each other. Our handler should have been this:

~~~javascript
{
  handler: async ({ accounts: [account] }) => {
    if (password !== password_again) {
      throw new f.httpErrors.preconditionFailed(`Passwords should match.`)
    }
    return { state: true }
  },
}
~~~

Unfortunately, the following code produces an attack vector called `Timing attack`. When searched upon it's clear that `eslint` only checks for the name of the variable `password` and this is a false positive in terms of security. But for the sake of this article, let's continue on investigating the cause of it and try to improve our code. (Make it hacker proof)

![Img](https://a.storyblok.com/f/98098/1280x720/a115be2373/hackerman.jpeg)

## Let's start by feeling like a hacker from now on

In cryptography, a timing attack is a side-channel attack in which the attacker attempts to compromise a cryptosystem by analyzing the time taken to executive cryptographic functions.

If we were calculating a SHA hash according to the password we got from the input, the execution time of calculating that particular hash would have been directly correlated with the length of the input.

Additionally, information can leak from a system through measurement of the time it takes to respond to certain queries. (According to Wikipedia)

In order to resolve this side-channel attack method, there is a specific function in `crypto` library in Node.js

### Here comes the `crypto.timingSafeEqual(a, b)`

According to the fantastic Node.js contributors and developers, here's the definition of this function:

~~~
This function is based on a constant-time algorithm. Returns true if a is equal to b, without leaking timing information that would allow an attacker to guess one of the values. This is suitable for comparing HMAC digests or secret values like authentication cookies or capability URLs.
~~~

So our following code should have been the following:

~~~javascript
{
  handler: async ({ accounts: [account] }) => {
    if (
      !crypto.timingSafeEqual(
        Buffer.from(password),
        Buffer.from(password_again),
      )
    ) {
      throw new f.httpErrors.preconditionFailed(`Passwords should match.`)
    }
    return { state: true }
  },
~~~

**P.S.**: Since we're not comparing two hash values or making any cryptographic calculations, this is absolutely unnecessary and a costly operation.

Timing Attacks on Node.js

While working on an application, I've come to a situation where I needed to transfer some highly sensitive data between the backend and the client. Even though theoretically, I should have used ECDH to transfer the keys of AES and then to do the decryption process on the mobile application itself, for the sake of simplicity and the delivery, I've omitted that part right now.

### The problem

Simply, I wanted to share an object of configuration to the client app from the backend. The request was on SSL, but we all know that a MITM attack can be possible. So, I needed to encrypt the data on the backend and decrypt it on the mobile application. I'm trusting the compilation process of iOS for the security of the AES secret and the IV.

### The solution

On the backend side, this is what I did:

```javascript
const PromiseRouter = require('express-router-wrapper')
const router = new PromiseRouter()
const crypto = require('crypto')

const iv = process.env.VPN_AES_IV
const secret = process.env.VPN_AES_SECRET

router
  .get('/', async (req, res) => {
    const text = {key: "value"}

    const cipher = crypto.createCipheriv(
      'aes-256-cbc', 
      Buffer.from(secret), 
      Buffer.from(iv))

    let encrypted = cipher.update(Buffer.from(text), 'utf8', 'hex')
    encrypted += cipher.final('hex')

    return {
      data: encrypted.toString('hex')
    }
  })

module.exports = router.getOriginal()
```

On the iOS Swift (4.2) side, please do this:

```swift
import CryptoSwift

let AES_IV: String = ""
let AES_SECRET: String = ""

func dataToByteArray(data: NSData) -> [UInt8] {
    let pointer = data.bytes.assumingMemoryBound(to: UInt8.self)
    
    let buffer = UnsafeBufferPointer(start: pointer, count: data.length)
    
    return Array<UInt8>(buffer)
}

extension String {
    func aesEncrypt() throws -> String {
        let encrypted = try AES(key: AES_SECRET, iv: AES_IV).encrypt([UInt8](self.data(using: .utf8)!))
        return Data(encrypted).base64EncodedString()
    }
    
    func aesDecrypt() throws -> String {
        let key: [UInt8] = Array(AES_SECRET.utf8)
        let iv: [UInt8] = Array(AES_IV.utf8)
        
        let encryptedData: NSData = self.hexStringToData()
        let encryptedBytes: [UInt8] = dataToByteArray(data: encryptedData)
        let decryptedBytes: [UInt8] = try AES(key: key, blockMode: CBC(iv: iv)).decrypt(encryptedBytes)
        
        return String(bytes: decryptedBytes, encoding: .utf8)!
    }
    
    func hexStringToData() -> NSData {
        let data = NSMutableData()
        var temp = ""
        for char in self {
            temp += String(char)
            if temp.count == 2 {
                let scanner = Scanner(string: temp)
                var value: CUnsignedInt = 0
                scanner.scanHexInt32(&value)
                data.append(&value, length: 1)
                temp = ""
            }
        }
        return data as NSData
    }
}
```

Before running your application, make sure that you've set up a Podfile and added `pod "CryptoSwift"` into it.

Cross platform encryption with AES between Swift and Node.js

I'm quite excited about writing about mobile application development. It has been in my mind for quite some time now. Before going into discussing my experience on these technologies I want to give a brief about my background.

I'm a Software Architect and a Full Stack Developer who was working with JavaScript for the past 6 years. Since the old days of JavaScript with ES5, the language has grown a lot. It's quite obvious. But it's important to remember our past to understand our future.

So, let's dive into the technologies!

### Cordova

I don't think it's fair for me to write about Cordova since I'm not an active developer for the past 4 years. Back in the days, a simple animation using CSS3 Keyframe animation was not working as intended in Android devices. Since they were using the default browser and not the Chromium it was intended to run in. Since those days, Cordova has evolved and started to ship itself with a smaller version of chromium inside itself.

Being able to run your website as a mobile application using Cordova was and still is a really interesting and fascinating feature for most of the web developers who just wanted to try the mobile application development.

Additionally, for a team who focuses not only on a specific technology but on JavaScript and it's ecosystems, it's really an interesting investment to write your own PoC using Ionic (Angular). But the very thing it makes Cordova strong does also make the technology weak compared to others. The web.

![Cordova App Architecture](https://a.storyblok.com/f/98098/843x667/0154fbed3c/cordovaapparchitecture.png)

#### Main Issues

- Browser layer of the application and the communication between the native code through it.

- WKWebView being the only browser support for iOS devices and the inconsistencies between browsers (Android vs iOS).

> Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine.

- All communication must go through the HTML Rendering Engine (in iOS: WebView) and causes the performance of the application to have a strict correlation with the browser.

### React Native

When React Native was first released it was quite a hype. The technology was unstable, but the promise it brings with it was quite fascinating!

Before continuing to my thoughts on React Native, let's dive into the React Native ecosystem.

Up until October, Facebook was using its own fork of open-sourced React-Native. Since it came with extra pullbacks and effort, they switched to using the open sourced one. (You can see some issues where a Facebook developer doesn't encounter a specific bug, even though the same functionality was used inside Facebook itself, but because of Facebook using its own fork.)

Facebook releases a new version every month, up until September (I guess). After that, they started to release every 2 months (as far as I observe).

![React Native vs Swift: Performance Comparison](https://a.storyblok.com/f/98098/800x464/4221c87908/react-native-cpu.png)

Even the performance comparison with native apps showed a lot of promise both in React-Native and in JavaScript. Even in 2017, we wrote a production ready app all in React-Native. It was going great. Everybody was happy. The code was shipped fast, and since most of our developers had a JavaScript background, we were delivering on time and shipping production quality apps.

Until the time I needed to write my own plugin to communicate with Swift side of the app through the JavaScript bridge, I was quite happy with it. Even, I suggested using it in my latest startup *SchoolApply*.

The breaking changes in React Native caused my native code to misbehave due to unknown changes made by **react-native-git-upgrade** module which React Native and Facebook suggests to update the core itself.

#### Main Issues

- It's main dependency React and inconsistencies between the React-Native core and React.

- React still doesn't follow the Semantic Versioning. From my perspective, software which is 4 years old, shouldn't be in 0.5X.XX.

- Inconsistencies with native modules due to the breaking changes that happen to React-Native core a lot. (This is one of the main reason that React-Native defends of it being in 0.5X version, but this is again the main reason to use Semantic Versioning: to keep track of breaking changes and to inform developers about the ecosystem and deprecation)

### Swift

It's quite unfair for me to judge a language by it's cover since I've been writing it for the past month but let's give it a shot.

I had a quite prejudice since I thought React-Native or Cordova was doing the same exact thing as Swift: A mobile application.

Every code written in Swift has a purpose. Yes, even the UITableView. It creates pain for new developers to get used to it and forces the user to use mainly XCode for development, even though there are solutions on the internet for using VSCode, Sublime or else.

The auto layout constraints are quite hard for a new developer. There are really great libraries such as SnapKit, Cartography exists which aims to solve this ambiguity, but still not the default way of doing it.

Even though all of the things above, the best experience I had as a developer is with Swift. There's no JavaScript bridge, WebView to get yourself bound into. You can use any library you want, with unlimited access to the device itself.

Software engineering

I'm sharing the experience I've gained in the past 10 years.