DEV Community: Rohit Jacob Mathew

Online Safety: A Guide to Protecting Yourself

Rohit Jacob Mathew — Mon, 20 May 2024 15:30:00 +0000

Navigating digital accounts safely is a concern for many in the modern age. Digital accounts have become an integral part of our daily lives, from email and online banking to accounts on ride-sharing platforms like Uber and e-commerce platforms like Amazon, protecting our digital lives online is becoming imperative

When computing began, we used computers for complex calculations on individual machines. Gradually, we started connecting these machines through the internet, leading to the dot-com boom. This boom resulted in the creation of many websites like chat rooms and forums. To access these, you needed to identify yourself, which led to the use of the common username and password system we use today to create accounts. This username and password became a way to uniquely identify a person and their account on these sites, forming a type of digital identity.

Nowadays, some of the most common incidents we see are phishing scams, identity theft, socially engineered attacks, ransomware, and compromised or weak credentials. Most, if not all, of these are directly or indirectly related to our digital identity and how we access it. Therefore, we need to ensure we secure ourselves online.

How To Secure Yourself Online? 🙋

I will discuss one aspect of securing yourself online, which relates to digital accounts and how we access them. The most recommended strategy for that is:

Use a passwordless login method like Face ID, Fingerprint Login or Passkeys.
Use a password manager like BitWarden or 1Password for sites that still require a username and password.
Implement multi-factor authentication (MFA) to verify your identity. This can include a Time-Based OTP (TOTP) or a deep link verification through email.

Let me also share the strategy I use:

I currently use 1Password as my password manager.
I have TOTP or passwordless MFA implemented on most sites.
I have removed most social logins and Single Sign-On.
I regularly conduct a security audit to see who has access to my data.
In the event of a data leak or hack, I immediately change my passwords.
Passwordless account creation using passkeys is a recent improvement, and I will likely start adopting them soon.

But ... 🤔 I'm Still Confused. Why Should We Do All This?

Good question. Let's explore why we find password-based logins inefficient, inconvenient, and frustrating.

Let's start with a login screen. You see above the traditional username/password login or signup page and a few social logins. These are currently the most common methods of accessing an account. Let's examine how these methods contribute to feelings of inefficiency, inconvenience, and frustration.

Inefficient

We Create Terrible Passwords - Below are some of the most common passwords in the world. There are open-source lists of these passwords that hackers use. Simple passwords like these or those related to you are not secure at all. They can easily be guessed from the list or with a little social engineering.

We Reuse the Same Passwords - To make things easier, we often use the same passwords for multiple accounts. This is very insecure because if one account is compromised, a hacker can easily access other accounts.
Compromised Social Logins - While social logins are easier to use, they also present a single point of failure. If one social login is compromised, it can lead to other accounts being compromised as well.
SMS & Voice-Based Multi-Factor Authentication (MFA) Can Be Hacked - While MFA has improved security, hackers have adapted and found ways to intercept SMS or voice-based MFA. Therefore, these methods are no longer the most secure.

Note: If you visit the site haveibeenpwned, you can see which of your data has been compromised.

Inconvenient

Resetting Passwords is Not Easy - When we forget our passwords, we often have to go through multiple steps to regain access to our accounts.
Password Requirements Are Sometimes Hard To Remember - Creating a new password that meets all the security requirements, such as including uppercase letters, numbers, and special characters, can be difficult to remember.
Social Logins Might Not Work Sometimes - With recent downtimes of social media sites, your logins might also face interruptions.
Multi-Factor Authentication (MFA) Can Add Friction - MFA often requires an extra step and is linked to a device, which can complicate the process. Additionally, backing up and recovering MFA methods is not straightforward.

Frustrating

Remembering Different Passwords - Memorable passwords are easy for hackers to guess or crack. It's frustrating to have different passwords for various accounts and to remember each one.
Social Login Providers & Data Privacy - Some social login providers or websites may share or sell their user data to third-party entities. This means that when you use social logins, your personal information, browsing habits, and other data might be accessed by companies you didn't intend to share it with.
Multi-Factor Authentication (MFA) Not Working - SMS or voice calls containing the authentication code not being received, delays in receiving push notifications or Time-based One-Time Passwords (TOTP) can expire are a few examples. These issues can cause significant frustration and hinder the login process.
Multi-Factor Authentication (MFA) Abuse - There has been an increase in hackers abusing MFA to access accounts. They exploit MFA solutions that send sign-in approval notifications after account access attempts, knowing that people often get frustrated by a flood of messages. Hackers have breached Uber, Microsoft, and Cisco using this method.

Right, So Why Is The Recommended Strategy Better? 😅

Let's break down the recommended strategy:

Use a Passwordless Login Method

Passwordless methods are more secure than password-based logins. If you want to know why, you can read my article on How Does Face ID or Touch ID Work. In simple terms, passwordless methods like Passkey use biometric authentication along with device identifiers to enable multifactor authentication (something you are and something you have) instead of a password (something you know).

This approach is not only easier and more secure but also resistant to many of the issues we discussed earlier. Although still new, there has been a significant industry push to adopt this, especially with the rise of biometric authenticators in our devices.

Note: You can find a list of websites and apps that support passwordless login or MFA, along with instructions on how to set it up, at passkeys.directory.

Use a Password Manager for Sites That Still Require a Username and Password

While not every site has adopted passwordless logins, a better way to secure your accounts that still use passwords is by using a password manager like Bitwarden or 1Password. They help you create strong, unique passwords and remember them easily. Most password managers come with autofill features that make it easy to use across devices.

While they can be a single point of failure and might be a bit of a hassle to set up initially, the benefits far outweigh the drawbacks. Remembering just one master password to manage your accounts securely is much better than dealing with the issues mentioned earlier.

Note: 1Password (the password manager I use) has provided more details on what happens if they are hacked. While there have been recent hacking incidents, I am not aware of any compromised data.

Implement Multi-factor Authentication to Verify Your Identity

Multi-factor Authentication (MFA) is a security measure that requires users to provide more than one form of identification to access their accounts. This typically involves a combination of something you know, like a traditional password, and something you have, such as a one-time password (OTP) sent via SMS or email. By adding this extra layer of security, MFA significantly reduces the risk of unauthorized access, even if your password is compromised.

Implementing MFA is a crucial step in protecting your online accounts and personal information. It may take a bit of extra time during the login process, but the added security is well worth the effort.

Note: Most websites and services we use provide 2FA. You can check based on your use case at 2fa.directory

Conclusion

This article explores common security threats and offers strategies to protect yourself online. Some recommendations include using passwordless login methods like Face ID or Passkeys, using password managers like 1Password, and implementing multi-factor authentication (MFA). These measures can greatly improve your online security and reduce the risk of unauthorized access to your accounts.

Hopefully, this article helps you understand why online security is important and enables you to stay safe on the internet.

Thanks for reading! I really hope that you find this article useful. I invite you to participate in the discussion in the comments below, I'm always interested to know your thoughts and happy to answer any questions you might have in your mind. If you think this post was useful, please like the post to help promote this piece to others.

If you want to read more of my articles, visit my blog

Thanks again for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter

How Does Face ID or Touch ID Work? Intro to WebAuthn

Rohit Jacob Mathew — Wed, 13 Apr 2022 15:07:08 +0000

Most of us are used to logging into different accounts using a password. For years this has been the norm but passwords also face other security issues:

They are extremely annoying when we don't remember them and even harder to reset
They can be quite insecure with the most common password being password or 123456
Phishing attacks are commonplace in today's internet era and using this hackers can steal your passwords

Would it not be simpler to move towards a more passwordless login? A place where we don't have to remember or have to enter passwords to gain access to our accounts? One such passwordless solution is WebAuthn.

What is WebAuthn? 😅

The Web Authentication API (also known as WebAuthn) is an API that enables strong authentication with public-key cryptography, enabling passwordless authentication and/or secure second-factor authentication without SMS texts.

Let's break that down to quickly understand:

Public Key Cryptography - So we use a key-based authentication (public and private key) to login and not a password. If you are not sure how it works I suggest watching this video.
Passwordless Authentication - In this type of authentication we will not be using a password to login but will use some form of user interaction to verify and login. This uses a hardware authenticator like a fingerprint sensor on your device or a YubiKey.
Secure Second-Factor Authentication Without SMS Texts - Two-Factor Authentication today is predominantly driven by SMS-based OTP but these are also susceptible to SIM swap. SIM swap is essentially taking control of someone’s phone number, and tricking a carrier into transferring it to a new phone. A two-factor authentication scenario-driven through a hardware authenticator using WebAuthn would be a safer solution to the above problem

It is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. Web Authentication works hand in hand with other industry standards such as Credential Management Level 1 and FIDO 2.0 Client to Authenticator Protocol 2.

How Does It Work? 🤔

So like every other login situation:

A user would be prompted for a username to identify them.
The browser would then prompt the user to use their hardware authenticator and verify themselves.
On successful authentication, you would be logged into the system.

Now what we don't see is a lot of what goes on in the background to facilitate this process. Let me explain a little more.

Registration Flow

In this process, a new set of key credentials are created against the username entered by the user. This key credential is the crux of the process which enables us to make sure this authentication is in a passwordless manner.

There is a simple 8 step process that takes place:

A user clicks on the register button on a site on their browser (user agent)
The authenticating server (relying party) issues a challenge (a random set of data sent as an array) to the user's browser to be able to enable WebAuthn login
The browser sends this challenge to the authenticator device
The authenticator device then prompts the user to authenticate themselves. This would be different based on the device. e.g - Touch ID on a Macbook or touching a YubiKey
Once the user authorizes the authenticator device, the authenticator will then create a new key pair (a public and private key) and will then use the private key to sign the challenge
The authenticator device will then return the signed challenge, the public key as well as details pertaining to the process back to the authenticating server
The authenticating server will then confirm the authenticity of the private key by using the public key to ensure the challenge was signed by the private key
It will then store the received details against the username for future use and respond that the user is registered

Authentication Flow

Authentication is a similar process where the above-generated credentials are used to verify the user's identity by going through a signed challenge process again.

There is a simple 8 step process that takes place:

A user clicks on the login button on a site on their browser (user agent) and enters their username
The authenticating server (relying party) issues a challenge (a random set of data sent as an array) to the user's browser along with the saved private key ID registered with the username
The browser sends this challenge & private key ID to the authenticator device
The authenticator device then prompts the user to authenticate themselves. This would be different based on the device. e.g - Touch ID on a Macbook or touching a YubiKey
Once the user authorizes the authenticator device, the authenticator will then retrieve the generated key pair saved on it with the provided private key ID and will then use the private key to sign the challenge
The authenticator device will then return the signed challenge as well as details pertaining to the process back to the authenticating server
The authenticating server will then confirm the authenticity of the private key by using its saved public key to ensure the challenge was signed by the private key
It will then log the user in

That Sounds Awesome 😮

Absolutely. Let's quickly see some of the benefits:

Private/Public Key Based Authentication - It's a more secure way to authenticate user compared to the current norm of password-based authentication as it uses asymmetric cryptography by default
Phishing Resistant - WebAuthn is resistant to phishing attacks due to the domain name being stored on the authenticator. This makes it harder for hackers to be able to spoof websites and gain access to credentials
Store Public Data in Your DB - Only public data is stored in the DB. No sensitive data such as passwords are required to be stored in this flow
Fine-Grained Control - You can control what sort of user interaction you want as a part of the flow for example a specific hardware device
Better UX - A user won't need to remember any password or such and will only need to use a hardware authenticator to be able to login to the device
W3C Recommendation - This means it should be supported by all major browsers across devices

and lastly NO MORE PASSWORDS

All that being said it does have some issues which are still to be solved:

User Credential Management - The user experience with respect to credential management is still in a very primitive state
Cross-Device Credentials - Being able to pass credentials from one device to another is not very easy unless you use a roaming hardware authenticator like a YubiKey
Lost/Stolen Authenticator Device Recovery - In case you don't have access or lose your roaming hardware authenticator, the fallback scenario is generally a password to gain access to an account but would need to be explicitly setup
WebAuthn Might Replace Passwords - WebAuthn is still in a very early phase and is slowly being adopted and supported. It might replace password-based login in the future but it might be a while before we see that happening. Note - this doesn't replace things like token-based authentication flows like OAuth or OIDC as well as identity providers like Auth0, Okta, Google, etc

Conclusion

WebAuthn is a much more secure authentication flow that is phishing resistant and only stores public data on a database with most private data generally stored on the hardware authenticator only. It makes use of asymmetric cryptography to do a user check and provides a much better UX compared to the existing login flow.

Currently, WebAuthn is majorly being driven as a two-factor authentication or universal 2nd factor workflow but could possibly replace password-based login in the future.

Hopefully, this article enables you to understand what WebAuthn is and how it works.

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter

Appendix

The following have been great material that helped me write this article:

Web Authentication (WebAuthn) Credential and Login Demo by Auth0
WebAuthn Specification Doc
WebAuthn Presentation by Sam Bellen
Guide to WebAuthn
Web Authentication API MDN Docs
WebAuthn Is Great and It Sucks by Okta
What is WebAuthn? by Okta
What is WebAuthn: Logging in with Touch ID and Windows Hello on the web by Michelle Marcelline

How to Extend Your Login Flow With Auth0 Actions

Rohit Jacob Mathew — Fri, 17 Dec 2021 14:46:10 +0000

I recently attended a training session with the Auth0 Dev Rel team on a very cool new feature they have added called Auth0 Actions. In this article, I am going to explain what is Auth0 Actions, why to use them, and how to set one up.

What are Auth0 Actions?

Actions are secure, tenant-specific, versioned functions written in Node.js that execute at certain points during the Auth0 runtime. Actions are used to customize and extend Auth0's capabilities with custom logic.

Above you can see a sample flow where once the user logs into the system, you add a trigger to verify the user's identity using Onfido and then confirm consent using OneTrust before completing the login flow and issuing the token.

In brief, an action is a programmatic way to add custom business logic into your login flow.

Why use Auth0 Actions? 🤔

1) Extensibility - Built to give developers more tooling and a better experience in their login workflows.

2) Drag N Drop Functionality — The flow editor lets you visually build custom workflows with drag and drop Action blocks for complete control.

3) Monaco Code Editor — Designed with developers in mind, you can easily write JavaScript functions with validation, intelligent code completion, and type definitions with TypeScript support.

4) Serverless Environment — Auth0 host's your custom Action functions and processes them when desired. The functions are stored and run on their infrastructure.

5) Version Control — You have the ability to store a history of individual Action changes and the power to revert back to previous versions as needed.

6) Pre-Production Testing — Your personal Actions can be drafted, reviewed, and tested before deploying into production

How do I set one up? 😮

For the purpose of this demo, we are going to be creating an action to enforce Multi-Factor Authentication (MFA) for a specific role. I will take you through the process of:

Creating a role
Adding users
Setting up a demo application
Creating an Action to enforce MFA
Testing the code

Let's get started:

1) Login to Your Auth0 Account

The first step to secure your application is to access the Auth0 Dashboard in order to create your Auth0 application. If you haven’t created an Auth0 account, you can sign up for a free one now.

2) Create an Application

Once in the dashboard, move to the Applications tab in the left sidebar.

Click on Create Application
Provide a friendly name for your application (eg - Test Actions App) and choose Single Page Web Applications as an application type.

From the quick start tab choose React. Download the sample app. This will have most of the necessary details already in place.

We also need to set up a few settings for this application. Choose the Settings tab (next to quick start). Add your localhost URL to the following places:
- Allowed Callback URLs
- Allowed Logout URLs
- Allowed Web Origins

3) Setup Application

Unzip the code we downloaded in a location of your choice.
Open it in the code editor of your choice
Cross verify that the details of your application are correctly configured in src/auth_config.json

We will run this code locally so install the dependencies and run it in dev mode (so we have hot reload enabled). To do this npm install & npm run dev
Once the application starts you should be shown a SPA like below. If you click on Log In it will take you to your login box.

4) Setup Users and Roles

Click on the User Management tab in the left sidebar.
Go to the Users tab and click on the Create User button. We need to create 2 users:

1. Admin User
2. Test User

Remember these credentials as these are the test users we will use for this demo.

Go to the Roles tab and click on the Create Role button. Call the role Admin and once created go to the user tab and assign it to your Admin user.
Once this is done go back to your locally running SPA and try logging in with one credential. You should be able to access a user portal like below.

5) Setup Actions

Click on the Actions Tab in the left sidebar
Go to the Flows category
Select the Login Flow. This will run the flow of an action once the login process in your login box is complete.

Click on the + button in Add Action and select Build Custom.
Name it MFA for Role and leave the rest as is.

Once Created you come to a screen as follows

Add the below code into onExecutePostLogin function

  if (event.authorization != undefined && event.authorization.roles.includes("Admin")) {
      api.multifactor.enable("any");
  };

On the left side you can see a play button. This is your testing environment inside the actions editor. You will find the event object in which you can test the actions flow by adding Admin to the authorization.roles array.

When you add the Admin role you should see a response with MFA like below and when not present you should get an empty array.

Click on save draft & deploy. Go to the flow now and click on the custom tab on the right and you should be able to drag and drop the MFA for Roles action into the flow. Click on Apply such that this new flow will work with your login box.

You will also need to enable MFA on the Auth0 dashboard. Open the Securities tab and choose multi-factor auth. In the following screen enable One-time Password. This will enable users to use an application like Google Authenticator for a one-time password. There are other factors you can enforce as well like SMS or Email-based OTP etc but for this demo, we will be using just the one-time password.

In the policies section leave everything as is and save your changes.

6) Testing With Your Application

Now when you go to login in on the locally running application we should be triggered to do a MFA for the admin user. So let's test that.

Click on login and redirect to your login box. If you are logged in already, log out and then do the same.
Enter your admin users credentials

Once the login goes through as a success you will be prompted to authenticate with your preferred authenticator app. I used google authenticator and entered my OTP.

You will then be asked to consent to share your user data with the application.

Once you accept the above you should be logged in.

If you try the same flow with the test user you will notice that you are directly logged in post the consent page and no MFA request was triggered. This is because in our actions code as shown below you can see we look to see if the user roles have the Admin role and if so then we ask Auth0 to trigger a MFA workflow with any of the enabled MFA use cases of the tenant.

  if (event.authorization != undefined && event.authorization.roles.includes("Admin")) {
      api.multifactor.enable("any");
  };

Conclusion

Congrats you have just created a custom Auth0 Actions flow and tested it. This was a simple example to enable you to understand what they are, how they can be built and used in your workflows. There are many more complex flows you can build for and can find some examples provided by Auth0 below. Just click on the trigger and you will find specific examples.

Sample Actions Code

Hopefully, this enables you to understand what actions are and how you can use them in your login workflows.

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter

Appendix

The following have been great material that helped me write this article:

How To Manage Encryption at Scale?

Rohit Jacob Mathew — Wed, 27 Oct 2021 11:32:59 +0000

Recently at work, I came across an interesting method to handle encryption at scale called envelope encryption.

First of all, it increases security and helps you ease out the management of encryption keys. But it's also a highly recommended pattern by PCI-DSS (Security Standard for Credit Card Processing) and results in much stronger data privacy and data protection of Personally Identifiable Information (PII).

When we think of data there are 3 places we can think of encrypting data:

At Rest - On hardware storage devices like on a disk or in your devices
In Transit - In moving data between different locations like server to server through API calls
In Use - While it's being used by a server (New concept and still being researched)

We will be dealing primarily with encryption at rest and envelope encryption is a popular pattern recommended for it.

So What is Envelope Encryption? 🤔

This is a type of encryption that involves encrypting your data with a Data Encryption Key, then encrypting the Data Encryption Key (DEK) with a Customer Master Keys (CMK). You then store both the encrypted data and the encrypted DEK alongside each other in the database. This practice of using a wrapping key to encrypt data keys is known as envelope encryption.

Like mentioned there are 2 keys you need to understand first before we see how the encryption process takes place:

Customer Master Key (CMK)
Data Encryption Key (DEK)

Customer Master Keys/Root Keys/Key Encryption Keys (CMK)

These are symmetric keys used to encrypt, decrypt, and re-encrypt data. It can also generate Data Encryption Keys that you can use outside of the KMS system. They follow the below:

Access to these must be restricted to the least endpoints
Access to these should be secured through ACL
These keys must be stored in a location that is secure like a KMS of a Hardware Security Module (to comply with FIPS 140-2)

In systems like Google Cloud Key Management Service, you have a hierarchy of keys as seen below with more information to be found here.

Data Encryption Keys (DEK)

Data keys are encryption keys you can use to encrypt data, including large amounts of data and other data encryption keys. Unlike CMK's, which can't be downloaded, data keys are returned to you for use outside of the KMS. Some of the best practices for DEKs:

Generate DEKs locally
When stored, always ensure DEKs are encrypted at rest
For easy access, store the DEK near the data that it encrypts
Generate a new DEK every time you write the data. This means you don't need to rotate the DEKs
Do not use the same DEK to encrypt data from two different users
Use a strong algorithm such as 256-bit Advanced Encryption Standard (AES)

Encryption Process

API request is sent to KMS to generate Data key using CMK
KMS returns a response with Plain Data key and Encrypted Data key (using CMK)

Data is encrypted using Plain Data key
Plain Data key is removed from memory

Encrypted Data and Encrypted Data Key is packaged together as an envelope and stored

Decryption Process

Encrypted Data key is extracted from the envelope
API request is sent to KMS using Encrypted Data key which has information about CMK to be used in KMS for decryption
KMS returns a response with Plain Data Key

Encrypted Data is decrypted using Plain Data key
Plain Data Key is removed from memory

How is Envelope Encryption Different From Other Encryption Patterns? 🤔

Every service you build requires encryption at some point. This could be passwords or PII in a database, credentials for an external service, or even files in a filesystem.

Configuration Files

You can easily handle some of these situations with a configuration file but they pose their own security risks like:

Proper planning is needed to keep the data secure
Multiple formats are present e.g - YAML, JSON and XML to name a few
Exact storage locations may be hard-coded in the app, making deployment potentially problematic
Parsing of the config files can be problematic.

Symmetric Encryption

You can encrypt data using a symmetric key but they suffer from a major issue which is Key Management.

You need to find a way to get the key to the party with whom you are sharing data and if someone gets their hands on a symmetric key, they can decrypt everything encrypted with that key.

Asymmetric Encryption

You can encrypt data using Asymmetric Encryption which is considered as a standard now a days. Some of the cons of it are:

It is a slow process which makes its not suitable for decrypting bulk messages
When you lose your private key, your received messages will not be decrypted
If your private key is identified by an attacker, all of your messages can be read by him/her

Envelope Encryption

Some of the benefits offered by it are:

A combination of benefits from symmetric and asymmetric encryption - The data is encrypted using a DEK which follows symmetric encryption. The DEK is encrypted by a CMK which follows asymmetric encryption. By using asymmetric encryption, encrypted DEKs can be shared and unencrypted only by those with access to the CMK, mitigating the key exchange problem of symmetric algorithms.
Easier key management - Multiple DEKs can be encrypted under a singular root key and ease the management of keys in a KMS. You can also do more secure key maintenance by rotating your root keys, instead of rotating and re-encrypting all of your DEKs.
Data key protection - Because we encrypt the data key with the CMK, we don't have to worry about storing the encrypted data key. Thus, we can safely store the encrypted data key alongside the encrypted data.

Key Management Systems & Why it Works at Scale? 🤔

The biggest reason for Envelope Encryption and KMSs working at scale is Performance. Like we mentioned before Asymmetric Encryptions are typically slow and Symmetric Encryptions are very fast but the management of keys is the issue.

So in Envelope Encryption for a large quantity of data, you quickly encrypt it using symmetric encryption using a random key. Then just the key is encrypted using asymmetric encryption. This gives the benefits of asymmetric encryption, with the performance of symmetric encryption.

Key Management Systems like AWS KMS, Azure Key Vault, and Google Cloud Key Management Service gives you a fully managed service to store and manage encryption keys. These use envelope encryption internally, and they’re used by default in a lot of services that support encryption in cloud infrastructure providers like AWS, GCP, Azure, and others.

An ideal key management system should be highly available, it should control access to the master key(s), it should audit the key(s) usage, and finally, it should manage key(s) lifecycle.

Thus by having the above characteristics and by using envelope encryption internally, Key Management Systems are ideal to handle encryption at scale.

Summary

Envelope Encryption is one of the most trusted application security design patterns used at scale. It is the default encryption method used in services like AWS S3, GCP, and others.

Hopefully, this enables you to understand how you can encrypt/decrypt a large amount of data using the envelope encryption method at scale in a more trusted setup.

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter

Appendix

This article leans heavily on the following material:

Run A Postgres Docker Container on Oracle Cloud Infrastructure

Rohit Jacob Mathew — Thu, 29 Jul 2021 15:17:38 +0000

In this article, I want to show how I quickly ran a Docker container for free on Oracle Cloud Infrastructure. I made use of a VM in the Always Free Tier of OCI and for a side project set up a dockerized Postgres database.

Why Oracle Cloud Infrastructure

Oracle offers an Always Free cloud services. You can see the details below:

Note: the workload of a container has to fit in the shape of this always free VM: VM.Standard.E2.1.Micro, 1/8 OCPU, 1 GB RAM and up to 480 Mbps network bandwidth (see docs). The boot volume offers just over 45GB of disk storage. In order for the container to be accessible, the ports mapped on the VM to container also have to be configured in ingress rules in the security list. We need to install Docker ourselves in the VM; it is provisioned with just an Oracle Linux image.

Let's get started

1) Get yourself a tenancy and create a VM

The first thing we ought to do is create a VM. If you've got a cloud tenancy then you probably already know how to create an instance. If you're new to Oracle Cloud then watch the below video and create an "always free" VM by signing up at https://cloud.oracle.com/free:

Note: Most of the details like availability zone, image details, networking options are already pre-filled by Oracle and kept but can be adjusted if you want something specific. I went ahead with the standard settings.

The VM will now be provisioned — as is indicated:

After a little while, the VM is up and running — and has a public IP address assigned to it:

The situation at this point can be visualized as is shown in the below figure:

2) Setup Ingress Rules in Security List for VM to open up the ports required for whatever container you want to run

The VM is associated with a public subnet in a Virtual Cloud Network. The security list(s) for this subnet should be configured with ingress rules that make the required traffic possible to the port(s) that will be mapped to the container image. Open the details page for the public subnet. Click on the security list (or create a new one)

We will run the Postgres container image. The port we will map in the VM to the Postgres container is one we can choose ourselves. Let’s pick 5432 which is the default port for Postgres. we need to configure an ingress rule as below:

Source CIDR is set to 0.0.0.0/0; along with Source Port Range left blank (i.e. All) this means that this rule applies to any client.

3) SSH into the VM, install Docker

At this point, we have a running VM instance with just a Linux Operating System but no Docker. Let’s SSH into the VM using this command:

ssh opc@public-id-address -i private-key-file

Replace the public-id-address with the public IP assigned to the VM. Replace private-key-file with a reference to the file that contains the SSH private key

Now to install Docker, execute these commands:

sudo yum-config-manager --enable ol7_addons 
sudo yum install docker-engine -y 
sudo systemctl start docker 
sudo systemctl enable docker

To run Docker as a non-root user, read these instructions.

Run Docker Container Image

With Docker installed, we can now run the Postgres container image.

Run the container image with this command. This might pull the docker image from Docker Hub if not present already. Don't forget to add a different password for POSTGRES_PASSWORD:

sudo docker run -d -p 5432:5432 --name postgres -e POSTGRES_PASSWORD=mysecretpassword postgres

Use sudo docker ps to verify if the container is running. The above command will start a PostgreSQL database and map ports using the following pattern: -p <host_port>:<container_port>. Port 5432 of our container will be mapped on port 5432 of our host or server.

Now, let's access the container on your host or server. We will create a database inside our Postgres container.

sudo docker exec -it postgres bash

Now you are ‘inside’ your container. We can access Postgres and create the database.

root@12d48fde2627:/# psql -U postgres
psql (13.3 (Debian 13.3-1.pgdg100+1))
Type "help" for help.

postgres=# CREATE DATABASE testdb;
CREATE DATABASE
postgres=# \q

We are finished. You can exit your container (\q) and go to your local machine. Here you need some PostgreSQL Client tool installed like DBeaver or pgAdmin. Connect to the DB server by using the public IP as the host, 5432 as the port, postgres as the username, the POSTGRES_PASSWORD you entered while running the container as the password and connect to the testdb. Save the connection and you should now be able to access your DB.

Congrats, you have now run A Postgres Docker Container on Oracle Cloud Infrastructure!

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter

Appendix

This article leans heavily on the following material:

Run Always Free Docker Container on Oracle Cloud Infrastructure - Lucas Jellema
Connect From Your Local Machine to a PostgreSQL Database in Docker - Lorenz Vanthillo

Why Is a Social Login More Secure?

Rohit Jacob Mathew — Mon, 07 Jun 2021 16:13:43 +0000

I'm sure every developer would have written a demo login application at some point of time. We all start with the simple user defined ID and password. We then try to implement something like a social login as seen in the cover picture with say Google or Twitter.

There obviously is more of a complex process involved in setting up a social login but for a user its as simple as clicking a buttons to log in. The ease of not having to remember an ID/password and just being able to signup/login through the click of a button is extremely beneficial to the user

What if I Told You This Was Way More Secure? 😉

Social logins really help us achieve a few things:

Support for multiple devices
Single Sign On
Simple to implement
The ability to share data for users without having to release personal information
Ability revoke an active session i.e not allow a third party access to the login and data
There is no long lasting credentials being exchanged

So What Drives This Technology? 🤔

The underlying protocol used is something called OAuth. It is defined as:

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

Now I'm sure with the basic understand of social logins and the above definition we get some idea into this but let me use a simple example to explain how OAuth works.

I remember my friend Sumedh describing it with an interaction between a Mother, Father and their Son. Imagine that the mother wants some grocery from market and she wants the son to buy it for her.

Before I go into the conversation let me set some context.

Mother: The user of the application
Son: Third party client or in technical terms the OAuth Client
Father: The Social Account or in technical terms the OAuth Provider

The conversation could possibly be as such:

Mother: Hey son, go to market and bring me some coffee powder. Take the required money from your father.

Son: Okay.

Son (OAuth client) goes to father (OAuth provider)

Son: Hey dad, mom told me to take money from you since she wants some things from market.

Father (OAuth provider) asks mother (User) about the permission to give money to their son (OAuth client)

Father: Hey, shall I give him the money and how much?

Authorization of your application takes place here.

Mother: Yes, please give it to him.

Permission grant by mother (User)

Son (OAuth client) gets the required things from market and returns them to mother (User). Here returning things to mother (User) can be thought of redirecting the user (or logging him) to the third party site.

For a more technical understanding of how this works in code Richard Schneeman has this amazing video below to enable you to understand:

Now Lets Put This All in Context

Let's take the example of the DEV Community. If you wanted to create an account on the DEV Community using twitter what would happen:

Basically if the Sign up with Twitter button exists then the initial setup between the OAuth Client (Dev.to) and the OAuth Provider (Twitter) is already done.
The Client triggers a permission grant page of the OAuth Provider based on the credentials it received from the initial setup. This looks something like below

Once you login and grant the permission the OAuth Provider redirects you back to the client and the client gets a token to access your information from the OAuth Provider. This access token enables the client to get specific data from the provider
Based on that data the client then creates an account and logs you in

What Happens on the Successive Login?

Thats a good question. Now OAuth has multiple grant types and based on that we have different ways to get an access token from the OAuth Provider. For all subsequent logins the OAuth Client will hit the provider and generate a new access token to get access to the data and do the login.

Thus this enables us to achieve Single Sign On, the ability to share data for users without having to release personal information, ability to revoke access and the ability to not have long lasting credentials exchanged.

Conclusion

I hope this short blog post helps you understand why social logins are more secure than the traditional username/password. I will be writing about the different OAuth Grant types in the future and will be providing code examples as well.

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter

JSON Web Token (JWT) and why we use them?

Rohit Jacob Mathew — Tue, 15 Dec 2020 19:48:41 +0000

So I wanted to talk about how we use JWT at Turtlemint. What is JWT (JSON Web Token) you ask? JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as JSON objects.

Let me take you through the whole thing from scratch

Authentication vs Authorization

Authentication is basically what happens when users sign-in. We check the user's identity based on some credentials of their e.g username/password. Authorization, on the other hand, checks if the above-validated user is able to access a certain flow.

Now I am not going to dive into all the details of the authentication flow but a generic login form is the simplest example in which the client (e.g - browser) knows that this is an actual user and gets their details. It makes no sense to keep authenticating every single subsequent interaction of the user with a system as this will add extra processing time; and as the saying goes: time is money. Hence, we authenticate and then store specific data based on which we authorize the subsequent interactions.

The simplest solution to enable this authorization flow is session-based authentication. In this, the server will create a session for the user after the user logs in. The session id is then stored on a cookie on the user's browser. While the user stays logged in, the cookie would be sent along with every subsequent request. The server can then compare the session id stored on the cookie against the session information stored in the memory to verify the user's identity and sends a response with the corresponding state! This obviously is not an optimal solution when you scale the system and leads to a stateful implementation where we are dependent on a server to authenticate every request.

Sounds good. What does JWT have to do with this?

Good question. So token-based authentication like JWT is a much more scalable solution as JWT is stateless. That means the user state is never saved in the server memory but the state is stored inside the token on the client side itself. By transmitting these JWTs with requests to other parties, you can make those systems more secure too. Lets quickly run through the authentication and authorization flow:

First, the user logs on to the authentication server using an authentication key (it can be a username / password pair, or a Facebook key, or a Google key, or a key from another account).
The authentication server then creates the JWT and sends it to the user.
When the user makes a request to the application API, he adds the previously received JWT to it.
When a user makes an API request, the application can check whether the user is what he claims to be, using the JWT from the request. In this scheme, the application server is configured to be able to check whether the incoming JWT is exactly what was created by the authentication server (the verification process will be explained later in more detail).

Oh, interesting 🤔 So what does a JWT look like?

A JSON Web Token consists of 3 parts separated by periods.



header.payload.signature

Header

The header typically only contains 2 details: the type of token (JWT in this case) and the hashing algorithm used by the token such as RSA, HMAC, or SHA256. This generally uses HS256 by default.



{
 "alg": "HS256",
 "typ": "JWT"
}

Payload

The actual data pertaining to a user is what we call claims. These claims can be of 3 types:

Reserved claims: These are some predefined claims which are not mandatory but recommended to use. These help the application judge the authenticity of the token. Some of them are iss (issuer), exp (expiration time), sub (subject), aud (audience), among others. The full list is available here
Public claims: These can be defined at will by those using JWTs. To avoid issues they should be defined in the IANA JSON Web Token Registry. Here is some more information regarding public claims.
Private claims: These are the custom claims created to share information between parties that agree on using them. Examples could be specific values such as employee ID and department name.

In the below code snippet you can see different types of claims being used where iss is a reserved claim, name is a public claim and admin is a private claim.



{
  [...]
  "iss": "https://rohitjmathew.space",
  "name": "Rohit Jacob Mathew",
  "admin": false
}

REMEMBER: Do not put large data in claim sets. Claim sets are meant to be compact. Also, do not put sensitive information, since JWT can be decoded easily.

Signature

The signature is the most important part of a JSON Web Token (JWT). It is calculated by encoding the header and payload using Base64url Encoding and concatenating them with a period separator, which is then run through the cryptographic algorithm.



// signature algorithm
data = base64urlEncode( header ) + "." + base64urlEncode( payload )
signature = HMAC( data, secret_salt )

So when the header or payload changes, the signature has to be calculated again.

Put Together

Thus the JWT looks like:



token = encodeBase64Url(header) + '.' + encodeBase64Url(payload) + '.' + encodeBase64Url(signature)

token = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3JvaGl0am1hdGhldy5zcGFjZSIsIm5hbWUiOiJSb2hpdCBKYWNvYiBNYXRoZXciLCJhZG1pbiI6ZmFsc2V9.ZOCcJAceq0Uq3fuIfWA0FVT_BLi5o-iPvyN4rhZgBuo

Securing JWT

I'm sure if you took the above JWT and checked on jwt.io you could see all the data in the token. This brings up the question of how is this secure?

It's absolutely crucial to know that JWT's are generally encoded and not encrypted. It is a mechanism by which you can verify that the data is not tampered with and has come from a trusted source.

A simple way in which you can ensure that JWT's are secure is by ensuring your requests are sent on HTTPS endpoints in which all data being passed in the request is encrypted.

Now, JWT uses two mechanisms to secure the information within it- signing and encryption. The two standards that describe these security features of JWT are JSON Web Signature (JWS) and JSON Web Encryption (JWE). Let me give you a rundown on them.

Signing

The purpose of a signature is to allow one or more parties to establish the authenticity of the JWT. Say I change the values in the payload above on jwt.io and try using it from my client. Well, that's where we can use JWS to sign the token and let it verify that the data contained in the JWT has not been tampered with.

Now if you remember the signature is basically the encoded header and payload concatenated with a period and then run through a hashing algorithm with a secret key.

This signature attached at the end enables us to determine if the JWT has been tampered with because for any change in the data the signature will change. A signature, however, does not prevent other parties from reading the contents of the JWT. This is what encryption is designed to do.

Encryption

While signing a JWT provides a means to establish the authenticity of the JWT contents, encryption provides a way to keep the contents of the JWT unreadable to third parties.

An encrypted JWT is known as JWE (JSON Web Encryption) and, unlike JWS, its compact serialization form has 5 elements separated by dots. Similar to JWS, it can use two cryptographic schemes: a shared secret scheme and a public/private-key scheme.

Wow, 😮 That's so cool. So how do you use JWT at Turtlemint?

We predominantly use JWT to allow us to transfer data between multiple applications as well as between domains with greater security.

As we have multiple products across multiple domains, this results in us having to transfer data from one domain to another in a more secure manner. A common problem you will see when doing something like this is CORS issues. JWT tokens enable the sharing of these resources in small containers as a part of the API call while also enabling us to validate the data (to be authentic). We also have services that need to interact with each other over the internet and use JWT to pass user-related data between them more securely.

Additional Info

Use the ebook below to better understand JWT. This is provided by Auth0 one of the leading providers of authentication, security, and identity solutions.

I hope you were able to understand what JSON Web Token (JWT) is and a few instances where we use them at Turtlemint. As long as you understand the basic concepts behind it you should be able to use them across multiple scenarios to either authenticate or transfer data in a more secure manner. Do reach out or comment below interesting use cases you have used them in.

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn and happy to answer any questions you might have in your mind.