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.

Common Cyber Attack Vectors (Source)

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:

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

Table From Bad To Good On Protecting Your Account (Source)

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.

Login & Signup Page

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.

Common Passwords In The World (Source)

• 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 call 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:

Table From Bad To Good On Protecting Your Account (Source)

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.

What Is Multi-factor Authentication (Source)

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. If you think this post was useful, please share 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.

• 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 technique 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. It lets you implement passwordless authentication and/or secure second-factor authentication without SMS texts.

Let’s break that down to quickly understand the parts:

• 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.

WebAuthn 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 WebAuthn 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, they would be logged into the system.

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

Generic WebAuthn Flow

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:

1. A user clicks on the register button on a site on their browser (user agent).
2. 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.
3. The browser sends this challenge to the authenticator device.
4. The authenticator device then prompts the user to authenticate themselves. This would be different based on the device, for example   Touch ID on a Macbook or touching a YubiKey.
5. 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.
6. 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.
7. 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.
8. It will then store the received details against the username for future use and respond that the user is registered.

Registration Flow

The WebAuthn 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:

1. A user clicks on the login button on a site on their browser (user agent) and enters their username.
2. 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.
3. The browser sends this challenge & private key ID to the authenticator device.
4. The authenticator device then prompts the user to authenticate themselves. This would be different based on the device (again,  Touch ID on a Macbook or touching a YubiKey).
5. 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. It will then use the private key to sign the challenge.
6. The authenticator device will then return the signed challenge as well as details pertaining to the process back to the authenticating server.
7. 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.
8. It will then log the user in.

Authentication Flow

Benefits of WebAuthn

That sounds awesome, right? 😮 Absolutely. Let’s quickly see some of the benefits:

• Private/Public Key Based Authentication — It’s a more secure way to authenticate users 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 passwords 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.

Disadvantages of WebAuthn

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 or identity providers like Auth0, Okta, Google, and others.

Conclusion

WebAuthn is a much more secure authentication flow than simply using a password. It 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 it could possibly replace password-based login in the future.

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

Thanks for reading! I really hope that you find this article useful. 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 share it so others can see it, too.

Also, do feel free to connect with me on LinkedIn or Twitter.

In this article, I am going to explain what Auth0 Actions are, why you'd want 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. In it, 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? 🤔

Extensibility – they're built to give developers more tooling and a better experience in their login workflows.

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

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.

Serverless Environment – Auth0 hosts your custom Action functions and processes them when desired. The functions are stored and run on their infrastructure.

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.

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

How to Set Up Auth0 Actions

For the purposes 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:

1. Creating a role
2. Adding users
3. Setting up a demo application
4. Creating an Action to enforce MFA
5. 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 (like 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:

1. Allowed Callback URLs
2. Allowed Logout URLs
3. Allowed Web Origins

3) Setup Application

Unzip the code we downloaded in a location of your choice. Then 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 an 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 it's 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. Then 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'll come to a screen as follows:

Add the below code into the 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. When it's not present you should get an empty array.

Click on save draft and deploy.

Go to the flow now and click on the custom actions tab on the right and you should be able to drag and drop the MFA for Roles action into the flow. Click on Apply so 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 next screen, enable One-time Password. This will let users 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, 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 on the locally running application, you 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, 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 after the consent page and no MFA request was triggered.

This is because in our actions code, as shown below, you can see that we check to see if the user roles have the Admin role. If so, then we ask Auth0 to trigger am 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 help you understand what Auth0 Actions are, and how they can be built and used in your workflows.

There are many more complex flows you can build, and you can find some examples provided by Auth0 below. Just click on the trigger and you will find specific examples.

Sample Actions Code

Thanks for reading! I really hope that you find this article useful. If so, please share it so others can see it.

Thanks for reading! :)

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

Appendix

The following sources were really helpful in writing this article:

• Introducing Auth0 Actions - Auth0
• Auth0 Actions - Auth0 Docs

There is, of course, a more complex process involved in setting up social login, but for a user it's as simple as clicking a button 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 are no long-lasting credentials being exchanged

So What Technology Drives Social Login? 🤔

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 with a basic understanding of social login and the above definition you probably have some idea of how this works – but let me use a simple example to explain how to use OAuth.

I remember my friend Sumedh describing it as an interaction between a Mother, Father, and their Son. Imagine that the mother wants some groceries from the market and she wants the son to buy them 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 go like this:

Mother: Hey son, go to the 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 the 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 the market and returns them to mother (User). Here returning things to mother (User) can be thought of redirecting the user (or logging them) into the third party site.

For a more technical understanding of how this works in code, Richard Schneeman has this amazing video below:

Now Lets Put All of This in Context

Let's take as an example 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 granting page for the OAuth Provider based on the credentials it receives from the initial setup. This looks something like below:

Once you login and grant 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 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, the ability to revoke access, and the ability to not have long lasting credentials exchanged.

This all leads to a more secure experience.

Conclusion

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

Thanks for reading! I really hope that you find this article useful. 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 share it to help promote this piece to others.

Thanks for reading! :)

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

In short, I used a VM in the Always Free Tier of OCI, and for a side project I set up a dockerised Postgres database.

Let's get into the details a bit more now.

Why Oracle Cloud Infrastructure

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

Note that 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 the 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's provisioned with just an Oracle Linux image.

Lets get started.

Step 1 – Get yourself a tenancy and create a virtual machine

The first thing we need 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, and networking options are already pre-filled by Oracle. But you can adjust them if you want something specific. I went ahead with the standard settings.

The VM will now be provisioned as is indicated here:

After a little while, the VM will be 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:

Step 2 – Setup the Ingress Rules in the Security List for your VM

This lets you 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 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, and Source Port Range is left blank (that is, All) which means that this rule applies to any client.

Step 3 – SSH into the VM and 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.

How to Run the Docker Container Image

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

Run the container image with this command. 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.

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

And with that we're done! You can exit your container (\q) and go to your local machine.

Here you need a 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 as the password and connect to the testdb. Save the connect 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! I really hope that you find this article useful. 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 share it to help promote this piece to others.

Thanks for reading! :)

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

Resources

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

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 it:

• At Rest – on hardware storage devices like a disk or in your devices
• In Transit – while moving data between different locations like server to server through API calls
• In Use – while it's being used by a server (this is a new concept and is still being researched)

We will be dealing primarily with encryption at rest, and envelope encryption is a popular pattern for this use case.

So What is Envelope Encryption? 🤔

Envelope encryption involves encrypting your data with a Data Encryption Key, then encrypting the Data Encryption Key (DEK) with a Customer Master Key (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.

You need to understand these two keys before we see how the encryption process takes place:

1. Customer Master Key (CMK)
2. 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. They can also generate Data Encryption Keys that you can use outside of the KMS system. They follow the below rules:

• Access to these keys must be restricted to the least endpoints
• Access to these keys 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 (you can find more information 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 are as follows:

• You should 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)

Envelope Encryption Process

First, an API request is sent to KMS to generate Data key using CMK.

Then the KMS returns a response with Plain Data key and Encrypted Data key (using CMK).

Data is encrypted using the Plain Data key, and then the Plain Data key is removed from memory.

The Encrypted Data and Encrypted Data Key are packaged together as an envelope and stored.

Decryption Process

First, the Encrypted Data key is extracted from the envelope.

Then an API request is sent to KMS using Encrypted Data key which has information about CMK to be used in KMS for decryption.

The KMS returns a response with the Plain Data Key.

Then the Encrypted Data is decrypted using the Plain Data key, and the 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, like 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. But 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 a standard now a days. However, some of its cons 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, they can read all of your messages

Envelope Encryption

Some of the benefits offered by envelope encryption 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.

Why Key Management Systems Work Well at Scale

Envelope Encryption and KMSs working so well at scale because of Performance. Like we mentioned before, Asymmetric Encryptions are typically slow and Symmetric Encryptions are very fast but managing keys can be an issue.

So in Envelope Encryption, for a large quantity of data, you quickly encrypt it using symmetric encryption with 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 helps you 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! I really hope that you find this article useful. I'm always interested to know your thoughts and am happy to answer any questions you might have. If you think this post was useful, please share it so others can read it, too.

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

Resources

This article leans heavily on the following material:

• Google Cloud Data Encryption - Jayendra's Cloud Certification Blog -
• AWS KMS concepts - AWS
• AWS KMS and Envelope Encryption - Manish Pandit
• Cloud Architecture Pattern: Envelope Encryption (or Digital Envelope) with Public Cloud Providers Part 1 - Nilay Parikh
• AWS KMS Envelope Encryption - Chirag Modi
• Protecting data with envelope encryption - IBM
• Envelope encryption - GCP
• Encryption at rest in Google Cloud - GCP