password

passwordHash

Gain insights into securing Node.js applications: sanitize inputs, use HTTPS, encryption, explore authentication, access control, and protect against XSS, CSRF, and popular hacks.

Working_SNA_Docker.tar.gz

psql

psql-copy

run_spa

run_spa_node

run_spa_hash

compose

compose-copy

compose-copy-copy

run_spa-copy

app-demo-psql

This course is your guide for securing Node.js applications. You'll start by properly sanitizing user input and output, and then move on to some fundamental protocols, such as HTTPS and SHA. Passwords and encryption will be discussed next. More specifically, you will learn about different hashing algorithms and protecting your application from brute force attacks.

Following that, you'll explore concepts like authentication, access control, and obfuscation. You will also learn about XSS, CSRF, and other popular hacks near the end of the course.

By the end of this course, you will know how to secure a Node.js application, an in-demand skill to put on your resume!

A Guide to Securing Node.js Applications

## More problems
After collision attacks, the next problems to look out for are lookup tables. Both exploits keep a list of popular passwords and their resulting hashes. Rainbow tables are a little more complicated but similar. How do we combat this? Random salts. 


A salt is something that is appended to the password hash to make it unique.  Salt is also something that is added to the rim of a margarita to make it delicious.  Ah, margaritas.  Anyway.  So you take a random string (salt) and combine it with the plain-text password string to give a unique value.  This means that even with a lookup table of known password hashes, an attacker can't match your user’s password hash with the list of hashes.  Given two identical passwords, the resulting hashes will be unique.  A random salt is an essential piece of password security.

## Random isn't always random
Your salt needs to be random to be effective. Random !== random though. You don't necessarily need truly random numbers, but `Math.random()` won't be random enough either.

JavaScript's built-in `Math.random()` functions are seeded with data that can be manipulated and determined. They are not random enough. To produce a truly random number, you must include enough entropy in the source. **Entropy** is the amount of genuinely random information collected by the system generating your random number.  Most non-cryptographic random number generators, like `Math.random()`, use algorithms to produce their numbers. They do not have enough outside data to make the numbers truly unique. The data `Math.random()` produces can be manipulated and guessed by an attacker. By observing enough of the output of `Math.random()`, an attacker can reliably determine the future output. In fact, depending on the implementation, after returning as little as three values from`Math.random()`, it is possible to calculate all future values.

 You have been warned; you **SHOULD NOT** use `Math.random()` for your salts. 

> `/dev/random` and `/dev/urandom` are special files that serve as pseudorandom number generators for Unix like operating systems.

## `/dev/random`
Calling your server's `/dev/random` is your best bet to get true random on most systems. 
The issue with using this for login is that it blocks while collecting entropy from the system.  By collecting entropy, it collects environmental data from your system, like various #key# HW: Hardware #key# data, keyboard typing, mouse movements, and disk access to generate a buffer of random bits. It can take a long time to return, especially on servers that aren’t busy. I ran into this recently; a developer on my team used `/dev/random` to generate an activation code.  Everything seemed fine at first. After we deployed the project to its production server, requests ended up taking over 60 seconds. The server wasn’t busy because it was only hosting this project. This caused  `/dev/random` to block for a fair bit of time while it collected entropy.  What was the solution? `/dev/urandom`.

## `/dev/urandom`
`/dev/urandom` isn't considered truly random, but it is cryptographically secure.  It is regarded as secure enough for use in salts.  `/dev/urandom` will return a good, pseudo-random number immediately with no blocking.  `/dev/urandom` uses the existing entropy pool to generate that pseudo-random number secure enough for most authentication systems. If you’re writing the login page for nuclear launch codes, make the user wait on `/dev/random` but for that social picture sharing site, `/dev/urandom` is good enough.

In Node, the `crypto` and `bcrypt` modules provide functions we can utilize to make this easier.  For generating salts in particular, we can utilize `crypto.randomBytes()` or `bcrypt.genSalt()`. We will look at how these work in a later [lesson](https://www.educative.io/courses/securing-nodejs-apps/putting-it-all-together).


# More problems
After collision attacks, the next problems to look out for are lookup tables. Both exploits keep a list of popular passwords and their resulting hashes. Rainbow tables are a little more complicated but similar. How do we combat this? Random salts. 


# Random isn't always random
Your salt needs to be random to be effective. Random !== random though. You don't necessarily need truly random numbers, but `Math.random()` won't be random enough either.

JavaScript's built-in `Math.random()` functions are seeded with data that can be manipulated and determined. They are not random enough. To produce a truly random number, you must include enough entropy in the source. **Entropy** is the amount of genuinely random information collected by the system generating your random number.  Most non-cryptographic random number generators, like `Math.random()`, use algorithms to produce their numbers. They do not have enough outside data to make the numbers truly unique. The data `Math.random()` produces can be manipulated and guessed by an attacker. By observing enough of the output of `Math.random()`, an attacker can reliably determine the future output. In fact, depending on the implementation, after returning as little as three values from`Math.random()`, it is possible to calculate all future values.

 You have been warned; you **SHOULD NOT** use `Math.random()` for your salts. 

> `/dev/random` and `/dev/urandom` are special files that serve as pseudorandom number generators for Unix like operating systems.

# `/dev/random`
Calling your server's `/dev/random` is your best bet to get true random on most systems. 
The issue with using this for login is that it blocks while collecting entropy from the system.  By collecting entropy, it collects environmental data from your system, like various #key# HW: Hardware #key# data, keyboard typing, mouse movements, and disk access to generate a buffer of random bits. It can take a long time to return, especially on servers that aren’t busy. I ran into this recently; a developer on my team used `/dev/random` to generate an activation code.  Everything seemed fine at first. After we deployed the project to its production server, requests ended up taking over 60 seconds. The server wasn’t busy because it was only hosting this project. This caused  `/dev/random` to block for a fair bit of time while it collected entropy.  What was the solution? `/dev/urandom`.

# `/dev/urandom`
`/dev/urandom` isn't considered truly random, but it is cryptographically secure.  It is regarded as secure enough for use in salts.  `/dev/urandom` will return a good, pseudo-random number immediately with no blocking.  `/dev/urandom` uses the existing entropy pool to generate that pseudo-random number secure enough for most authentication systems. If you’re writing the login page for nuclear launch codes, make the user wait on `/dev/random` but for that social picture sharing site, `/dev/urandom` is good enough.

In Node, the `crypto` and `bcrypt` modules provide functions we can utilize to make this easier.  For generating salts in particular, we can utilize `crypto.randomBytes()` or `bcrypt.genSalt()`. We will look at how these work in a later [lesson](https://www.educative.io/courses/securing-nodejs-apps/putting-it-all-together).


Learn how to use salts to enhance security.

Introduction

Never Trust Your Users. Sanitize ALL Input!

HTTPS and Other Random Letters

Password Encryption and Storage for Everyone

Authentication, Access Control, and Safe File Handling

Safe Defaults, Cross Site Scripting, and Other Popular Hacks

A Pinch of Salt

More problems