Now that we have introduced the use of a database in a web app, it is crucial to secure the database from unauthorized and/or malicious access. In the old days, this is fairly easy to set up. However, due to the proliferation of cyber attack tools as well as much enhanced sophistication of black hat (malicious) hackers, one must be very careful when it comes to user authentication.
Essentially, user authentication is the mechanism to identify and ensure a user is who he/she claims to be. The identification part is usually quite easy, it can be a account name specific to a web app or an email address. The authentication part, however, is not as simple.
The most basic approach to authenticate users is to maintain both the identity and the plain-text password of a registered user in a database. This approach is considered ineffective against cyber attacks. Furthermore, any hack into the database will get to the actual passwords of every user for a web app.
The main issue with this approach is that the passwords are stored in plain text.
A widely accepted remedy to the tier 0 approach is to store the hash value of password instead of the plain-text password. This requires a little bit of explanation.
A hash function is a function that takes a string as input and returns a hash value. Depending on the hash function, the hash value can be a long string of seemingly random characters even if the input string is simple.
For example, SHA2 is a family of hash functions. Specifically, SHA2-512 returns a hash value of 512 bits (64 bytes).
The idea of storing the hashed value of a password is that even if the database is hacked, it is difficult (impractical) to reverse the hash value to the actual password. The authentication steps are as follows:
With a long hash value (such as that of SHA2-512), it is fairly unlikely that a hacker can derive the original password if the hash value itself is leaked.
However, any password-based authentication is susceptible to dictionary attack. A dictionary attack looks up common words used for passwords in a dictionary and try to hack into a system by going through the dictionary entries. To make matters worse, many users use the same password for different web apps. Cracking the password to one web app means a number of web apps are also compromised.
In addition to dictionary attacks, the password approach can also be compromised by key-loggers (both software and hardware), video camera filming a keyboard, and other methods of stealing the password.
This is often called second/multi factor authentication. The steps are typically as follows:
The second factor renders password theft pointless unless the thief also gains physical access to the mobile device of the target user.
Most mobile platforms such as Android and iOS now offer mechanisms to directly auto-fill the second factor field of a form from SMS messages.
Note that second factor by itself may not be secure. This is because the theft of a mobile device automatically means the theft of accounts (unless the mobile device itself is secured).
Tier 3 uses biometric authentication, such as fingerprints and face recognition. No biometric authentication that can done on a consumer mobile device is very secure against professionals. However, they are effective against general criminals.
The Power server is capable of sending outgoing emails, and this is sufficient to perform tier 2 authentication.
First of all, SMS gateway provides a mechansim to use email to send SMS text messages. To do this, a NodeJS script will need to use a command line command mail to send messages. If regular email (SMS via gateway) is preferred, this method also works.
In another module, we will get into the technical details to implement tier-2 (password and second factor) authentication.