What is 2 Way Authentication Using Node.JS ?

Authentication has progressively become an essential component of all web applications and sites. Long gone are the days of applications that easily executed an action without getting any details about the identification of the user who executed the actions. In this blog, we will analyze one of the most impressive (and easiest) ways of developing the security of your authentication procedure: two-factor authentication (2FA / MFA).

Two-factor authentication

2FA has become quite famous. As you may have believed, it works by giving an additional layer of authentication that is independent of the leading layer. Most applications create utilize of the usual username + password consolidation, though any two independent authentication technique may be associated. In the following paragraphs, we will analyze one authentication technique that has become famous for use as the second step in 2FA: the time-based one-time password algorithm (TOTP).

Time-based one-time password algorithm

TOTP is determined in RFC 6238. It is free and easy. There are many open-source implementations for both the client-side and server-side components. In appropriate, Google has developed an application that is openly available for Android, iOS and the web: Google Authenticator. This application permits us to integrate TOTP simply into our developments. We will analyze how to do so in the following sections, but first I'll give you a brief summary of TOTP and how it mostly works in two steps:

Enrollment: Permissive 2FA for a unique user.

Login: Utilizing 2FA to log in.

As you may have collected from the chart above, the main specification for TOTP to work is a shared secret. This shared secret commitments to be generated and then stored by both the customer- and the server-side parts of the system. This usually means that an "enrollment" stage is significant before making TOTP applicable in an application.

Another essential thing to keep in mind, as the name of the algorithm entails, the generated codes are time-dependent. The customer and the server need to adjust their clocks, and the codes become null after a certain amount of time.

Adding TOTP to your Node.js application

As you have seen in the preceding chart, adding 2FA with TOTP to an application requires two independent steps. In our e.g., the second step (the actual authentication) will be managed by passport-top, a passport.js approach that validates the user-entered TOTP code and requires approach to the user-specific key. We will also lack the user to install Google Authenticator (or another related app) to generate codes with his or her cellphone. The user may also prefer to use the Google Authenticator Chrome app.

You can get all the code from the following snippets here: app.js

Step one: enrollment

In our example, the first step will be managed manually by us. We will add code to generate a new irregular key and store it along with other customer authentication data.

After the usual passport.js and express.js setup, we add the fundamental Totp Strategy:

As frequent, passport will call this callback with the certain 'user' object as desterilized from the request. The 'user' object consists of a 'key' string that may be null. If the key is null, we will consider TOTP wounded and permit logins with just a username and password. If the key is present, we will require a supplementary input from the user before processing with the login. The key must be provided to passport as a byte array, but for comfort (and because Google Authenticator requires so), we store it as a BASE32 encoded string. The 'period' is the amount of time a single TOTP code is valid from the time it is requested to the time it is entered.

The enrollment step requires the customer to be already logged in (as this is fundamental to enable or disable TOTP in the server for each exact account). If the user prefers to enable TOTP, we present the shared secret as a QR code ready to scan and save in Google Authenticator:

If the user prefers to enable TOTP, we generate a new secret key anyway. Then we encode it in BASE32 format for simple storage and to display it to the user. The 'assureTotp' middleware makes assured that if 2FA is enabled, then the user has logged in utilizing a TOTP code.

Step two: a new authentication step

Once 2FA is enabled, logins will now have two steps: a username and password will be required as frequent, and then, a six-digit code will be input, which the user will demand to get from Google Authenticator every time he or she need to login. So, we will add the significant code to execute the login and permit the user to enter the code after the first stage is complete.

After the frequent username + password authentication, we check whether a TOTP code is appropriate. If so, we deflect the user to the "totp-input" page.

Otherwise we send him or her to the frequent place after logging in (in this case, for clarity, we just keep a totp-setup page as the main page after a successful login). Keep in mind that all places that require authentication want to check for both the basic login and the TOTP login (which is optional) for this to be protected. For instance:

And here are the implementations of the middleware components that execute the check:

As you can look, for the TOTP check, we make use of a temp variable ('method') inside the session. Session data is stored on the server, so this is secure to do. The customer just keeps a session ID.

Is this production ready?

In the earlier paragraphs we covered the fundamentals of 2FA. Here's what you want to keep in mind when going into production:

Phone or gadget unavailable: Recognize what happens if a user forgets access to his or her code-generating gadget or application (or shared-secret). Provide a means for the user to restore access to his or her account without negotiating security (email links, SMS messages, etc.).

Reset 2FA from backend: Depending on your utilize case, it may be fundamental to add the means to disable or reset 2FA data straight from the backend. Frequently, this is skillful by requiring the user to execute the enrollment step one more time after login.

Fallback for people who don't have smartphones: If a user prefers not to use a smartphone, any of the recovery techniques may be enabled forever.

Audit and notify users of changes: Provide acceptable ways for users to see if the authentication details (or techniques) have been changed or enabled in their accounts. This permits for new disclosure of suspicious activity. Automated emails are a best choice.

Encrypt shared secrets: Per RFC 6238, you should store shared-secrets utilizing a cryptographically protected reversible algorithm and keep the keys in memory only as long as fundamental. Do not reinvent the wheel; use extant and well-tested libraries for this.

It does not require a lot of infrastructure. Google Authenticator, Microsoft Authenticator, Authy and other TOTP applications are applicable in multiple platforms which creates approval simple. But don't forget to take into account the non-happy-path: people reboot their phone, it gets lost or lifted, or sometimes they don't even have one.

If you have any queries, write to us at info@vamediabox.com or if you are looking for Ecommerce Development Services, contact us at +91-9599449323