[Nodejs] Security: Broken Authentication

Written by peterchang_82818 | Published 2017/05/21
Tech Story Tags: security | javascript | nodejs | web-development | crack

TLDRvia the TL;DR App

Password cracking is equivalent to picking the lock on the front door of a house to break in, by @ChetanKarade

This is a note about Node.js security, by reading the amazing book Securing Node Applications by @ChetanKarade, which explains couple of common vulnerabilities in very simple way, and provides relevant npm modules as solutions to protect Node.js Web Apps.

Broken Authentication and Session Management attacks are anonymous attacks with the intention to try and retrieve passwords, user account information, IDs and other details, by appknox

Password Cracking is the most exploited threat among the OWASP Top 10. And the typical attack scenarios include :

. Exploiting weak account passwords . Passwords stolen from database breaches . Active session IDs stolen from a victim user’s browser or network communication . Bugs in password management features such as changing or recovering a forgotten password.

1. Brute-force Attack

The most guaranteed but time-consuming method to crack a password is the brute-force attack.

Brute force password cracking workall the letters, number, special characters that might be combined for a password and attempts them.

Brute-force attack tool :

Preventing brute-force attack:

7 rules to keep passwords safe:

  • Require strong passwords
  • Rate-limit maximum login attempts allowed per user ID or IP for a given time period
  • Lockout mechanism, preventing a user from logging in upon multiple failed attempts.
  • Console Log all login failures with metadata (such as IP address) and lockouts, and actively monitor it.
  • Secure password recover 。Requires the old password 。Secret question to prevent simple number, character 。Ensure that the forgot password and other recovery paths do not reveal the current password

2. Rainbow Tables Cracking

Rainbow Table is a large dictionary with pre-calculated hashes and the passwords from which they were calculated (by vilx).

This is a long table of [plaintext]-[encrypted] pairs for most common passwords. Attackers use it to look up the stolen password hash and get the corresponding plain-text password.

Preventing Rainbow Tables attack:

To protect against a rainbow-table attack, combine a random value, referred to as salt, with the password before encrypting it.

Example: Github (updated by @JamesK )

var bcrypt = require('bcrypt')var crypto = require('crypto')

var _hashFunction = (_password) => crypto.createHash('sha384').update(_password).digest().toString('base64')

const password = _hashFunction('123456')

bcrypt.hash(password, 12).then(console.log)

bcrypt.**hash**( … ) is a async function, because the hashing done by bcrypt is CPU intensive, so the sync version will block the event loop and prevent your application from servicing any other inbound requests or events, and it results that taking longer time to hack plaintext(more).

3. Session Stealing

Because HTTP is a stateless protocol, to remember a user, the server maintains a session identifier (SID) that is passed back and forth between the client and server. There are three ways an attacker normally goings about:

  • Guess the ID
  • Steal the ID
  • Set the ID

Implementation of Secure Session Management

HTTP is stateless, in order to associate a request to any other request, you need a way to store user data between HTTP requests.

Cookies and URL parameters are both suitable ways to transport data between client and server.

In session hijacking, an attacker steals the session cookie to enter the user ID or password.

Using techniques such as utilizing a network sniffer, which is a piece of malicious script injected by using a cross-site scripting (XSS) attack.

It is great that there is npm module for Secure Session Management, express-session.

When designing Secure Session Management, there are some tips:

  1. Never expose Session data on client side, only SID is stored on Cookie
  2. Never put Session on URL parameter
  3. Never store Session data in production environments (but DB)
  4. Use httpOnly flag, to ensure that the cookie is not accessible to JavaScript code running on the browser
  5. The secure flag ensures that the cookie is transmitted only on a secure HTTPS connection
  6. Set session timeout period
  7. Destroy session on logout

var session = require('express-session');

app.use(session({resave: false,saveUninitialized: true,secret: '...',cookie: {httpOnly: true,secure: true,maxAge: 1 * 60 * 1000 // 10 minutes}}));

Remark

Provided by @James K:

. When using the bcrypt library on npm is that it’s limited to a max length of 72 characters.

. When a null character (ASCII 0) ends up in the password somehow, everything after that is ignored because the underlying implementation uses c-strings.

. Problem is solve simply by hashing passwords with a digest algorithm and encode with base64 before hashing with bcrypt.

You may also like

[Nodejs] Security: Command Injection

Like this story? It is helpful to others? It helps me know if you’d like to see write more about his topic and helps people see the story, when tap the heart below.

Reference:

Node.js Security Checklist

Express: Production Best Practices: Security

https://blog.appknox.com/understanding-the-owasp-top-10-broken-authentication-session-management/

http://stackoverflow.com/questions/1012724/what-exactly-is-a-rainbow-attack

http://blog.teamtreehouse.com/how-to-create-bulletproof-sessions

Session Management Cheat Sheet


Published by HackerNoon on 2017/05/21