Having said that, the maths involved is highly complex and is something likely only PHD’s can understand but just like electricity, we don’t need to know how it flows through the wire to use it effectively.

The aim of this article is to provide a high-level overview and I’ll be sharing a detailed technical guide on how to encrypt data at a later date.

What is encryption?

Encryption is the process of converting readable information (plaintext) into an unreadable format (ciphertext) using a mathematical algorithm and a secret value called a key.

If someone happened to intercept a piece of encrypted data, it would simply look like a random sequence of letters, numbers and characters and nothing useful could be derived from it.

Fun Fact:

The oldest recorded example of encryption comes from Ancient Egypt. Egyptian scribes sometimes used non-standard hieroglyphs in inscriptions—swapping symbols or using unusual ones to obscure the meaning of religious texts and official records.

Types of Encryption:

Thankfully we’ve moved on from hieroglyphs so what does encryption look like in the modern age? At the heart of modern digital security are two types of encryption: Symmetric and Asymmetric.

Symmetric Encryption:

is the simplest form of encryption. It uses the same secret key to both encrypt and decrypt data.

Think of it like sharing a house key:

• You lock the door with the key

• Your friend unlocks it with the same key

• Anyone else who gets that key? #problem

It is very useful and heavily relied on because of how quick it is to encrypt and decrypt data using this method.

It’s used to protect:

• Hard Drives

• Databases

• VPN traffic

• Large files

Essentially anything that involves a large amount of data.

Algorithms like AES are the gold standard here. AES-256 is so trusted that governments, banks, and security professionals all rely on this to keep data safe.

Unfortunately, no matter how perfect something is, there’s often a small problem that can ruin the whole thing – such is life. In this case it’s not the encryption, it’s the key itself.

How do you safely give someone the secret key without someone else stealing it?

You can’t just email it (not secure).

You can’t shout it across the internet (absolutely absurd).

And writing it on a piece of paper is just plain stupid.

This is known as the key distribution problem, and it’s the reason symmetric encryption can’t handle the internet alone.

Asymmetric Encryption

What if we don’t need to worry about how we are going to get the secret key to the other person?

Instead of one key, it uses two, both keys are generated at the same time and are linked mathematically.

• A public key (share it with the world)

• A private key (keep it close to your chest)

Anything encrypted with one key can only be decrypted with the other.

So, if someone encrypts something with my public key which I can safely share with whomever, only I’ll be able to decrypt it as I should be the only person in possession of the private key from the same key pair.

Safely storing private keys is a complex topic and is well beyond the scope of this article, however if I’ve piqued your interest and you would like to learn more about this look into hardware security modules. They are physical computing devices dedicated to this amongst other cryptographic functions.

Asymmetric encryption solves the trust problem.

You can safely send encrypted data to someone without ever meeting them or sharing the secret key first. That’s kind of essential when you’re talking to millions of strangers on the internet.

This is why technologies like HTTPS, digital certificates, and secure email even exist.

Downsides:

Remember my point earlier about how there’s no such thing as perfect?

Asymmetric encryption is painfully slow compared to symmetric encryption.

For this reason it’s not used for bulk data — only for:

• Authentication

• Key exchange

• Digital signatures

It is secure and an excellent advancement – just not fast.

What now?

Sometimes, just sometimes there is a happy ending.. This is one of those times. Only because the two systems complement each other beautifully, so well in fact it’s almost as if they were made for each other..

Modern systems use hybrid encryption:

1. Asymmetric encryption is used to securely communicate the secret symmetric encryption/decryption key (remember the same key is used for both processes).

2. Symmetric encryption then takes over and does the heavy lifting.

Alone, each has flaws. Together, they’re the reason why the internet functions as well as it does. Without this we wouldn’t be able to securely browse sites, conduct online/ mobile banking or any form of online shopping etc..

Naturally, there is much more to this topic than what I’ve explained here. As mentioned earlier I will be creating a detailed guide on how to encrypt data and create digital signatures using both forms of encryption. I hope you find this brief overview useful.

The project can be broken down into two sections. The front end and the back end.

Front End

While some may consider this the easiest part of the challenge, to me this was the most time-consuming. I planned for my resume page to be a part of my blog so I dived in trying to build this out. The official guidance was to just write some simple HTML and CSS but naturally this was not going to be enough for my state-of-the-art blog. So, I bashed my head against the wall wrestling with a variety of “low code editors” which were often so confusing I would have been better off just taking a 100-hour web development course.

After much time in the desert, I arrived at the promised land in the form of Hashnode. I decided to use Hashnode to manage my blog and created a separate page hosted on a subdomain for my resume. With some DNS magic, I managed to get this to work, and this setup meets my needs perfectly.

DNS, Cloudfront, Hosting, SSL Certificate

With my web files hosted in a S3 bucket, I wanted to allow public access without allowing public access. This is possible with a CloudFront distribution and this also allows for the use of a secure HTTPS connection but this requires the creation of an SSL certificate which is attached to the CloudFront distribution.

As my main domain was dedicated to the blog, I chose to set up a subdomain to host my resume page. I used an alternative domain registrar to Route 53 but the certificate for the subdomain was successfully issued by Amazon Certificate Manager after creating CNAME records. My CloudFront distribution now had a custom domain name and facilitated HTTPS access.

Backend

To create a website visitor counter, we need a database to store this information. DynamoDB was used for this and to perform actions on the table a lambda function written in Python is used. We don’t want direct communication between the JavaScript code and DynamoDB so I used API Gateway to handle this aspect.

I encountered a few errors in this side of the woods with my DynamoDB table successfully updating when my API URL function was invoked but I still could not get the visitor counter to provide an appropriate response. After updating the response headers and debugging the JavaScript Code I managed to get it to work. To find out what was happening under the hood I used CloudWatch to log the errors from the API Gateway after configuring permissions for this in IAM.

A valuable lesson I learned while completing this section is that error logs are useful if you filter them properly. They act as a map guiding you to the right destination, without them you are often walking blind as you don’t actually know what the problem is and you’ll undoubtedly spend a lot of time lost at sea.

CI/CD and Automation

I did not want to have to keep reuploading files to S3 every time I made a change and manually invalidating the CloudFront distribution cache. While there are a few tools that can be used to build a CI/CD pipeline I settled on GitHub actions. I configured VS Code and Github through the use of SSH keys and Github and AWS through the use of access keys. I then created a YAML file with the workflow which describes which actions should be taken when code is pushed to a GitHub Repository.

While this is not particularly complicated, I found myself making simple errors that prevented the workflow file from executing. These include creating .github/workflows in another folder as opposed to the main folder and forgetting that you have to configure Github Secrets for every repository you create. Discovering the “empty commit” was useful as an issue I faced early on was that I could not push to Github if there were no changes (I would get the "everything is up to date" message). For example, this was a problem when I discovered the issue was that I had forgotten to set up secrets for the new repo and my code had not changed so I could not push to trigger the workflow.

Considerations

I plan to write this entire project as IAC. I am also aware that the security of this project could be strengthened by securing the API, ensuring services have only the permissions required, and the use of a WAF.

This extra layer of protection is referred to as multi-factor authentication - meaning you need more than your password to log in. There are several forms of multi-factor authentication, we'll quickly discuss the different options and how secure they are.

SMS

Many websites ask for your mobile number to provide you with an OTP (one-time passcode). While this option is better than not having any multi-factor authentication at all - it is still not particularly secure.

Hackers and fraudsters can intercept SMS messages through various techniques.

One of these techniques is an "SS7 Hack". SS7 is short for Signalling System No 7 which is the system that facilitates connections between mobile phone networks. Anyone with access to this system can intercept SMS messages, listen to voice calls and track target movements.

Another common method is "sim swapping" or "sim jacking". Irrespective of the name used, the method is the same, a hacker or fraudster attempts to convince your mobile phone network operator to port your number over to a new sim card in their possession. This is usually done through social engineering. Network operators are aware of this issue but it is still very much a present threat.

I think we can all agree that this option is not particularly secure.

Authenticator App

Many well-known applications can provide OTPs. These include Microsoft Authenticator, Google Authenticator, Authy, and many more.

These apps are straightforward to set up and relatively secure. The usual process involves scanning a QR code and entering the code produced to sync the authentication platform with the account provider.

If the OTPs are stored locally, a threat actor would have to compromise the device itself to access the code. If you are using a cloud-based manager the threat actor could potentially hijack the account. Irrespective, this option is more secure than using SMS as 2FA.

I'm sure advanced authenticator attacks exist, I've mentioned these two as general concepts.

Hardware Key

The hardware key is by far the most secure option when it comes to 2FA / MFA. In short, if you don't have access to the key you will not be able to access the account. This reduces the risk of compromise drastically as an actor would need the physical key + your password to gain access. Unfortunately, this also means that if you lose the key, you will also be locked out of your accounts, that is why it is recommended that you setup multiple keys using some as backups.

One of the more popular hardware keys on the market is from Yubico - they have a range of keys targeted at users of different platforms.

Note: While using a hardware key is the most secure option, many account providers will not allow you to just use a hardware key as your 2FA option. Most will insist that you also use an authenticator app or SMS 2FA. In this scenario, your security is only as good as the security associated with using an authenticator app or SMS 2FA.

The average person now has over 15 online accounts, ranging from social media such as Instagram & Facebook to email & online banking platforms. To deal with this major admin headache, users have resorted to using the same password for the majority, if not all, of their accounts. I’ll admit I have been guilty of this in the past (don’t judge). Naturally, the passwords are usually easy to remember and that often means weak- think CatDog1.

A strong password should consist of many characters - over 10 characters and you’re on the right track. They should also contain capitals, symbols, and numbers. An easy way to create a strong password is to use a password manager, which we’ll touch on shortly. Another suitable method is to create a sentence. e.g. £76-“The dog chased the cat around the house”.

As you can see this is a massive improvement on the CatDog1 password and is not particularly difficult to remember. Having said that, you may be filled with dread at the prospect of having to type this out every time you want to gain access to your account. There’s no rest for the wicked.

How are passwords stored?

An account provider with an understanding of good security practices shouldn’t be storing passwords in plaintext. Plaintext means that if anyone accesses the database, they can see your password, un-encrypted, in all its glory. If a hacker breaches the database, they’ll also be able to see your password..

To deal with this issue, websites usually store “the password hash” instead of the actual password. A hash generates a unique key from a value. These functions are one - way, meaning you cannot derive the input from the output, or in other words, once a password is hashed, it cannot be “un-hashed” by anyone.

The website stores the hash on its server, and when you enter your password into the login section, a hash is created and compared with the hash on the server eliminating the need to store plain text passwords. This is not without its issues as two different values could generate the same hash known as a “hash collision”. Different hashing algorithms present different risks of a collision, so it’s important a strong algorithm is used to minimize this risk - think SHA256. You can even use these algorithms to ensure the integrity of your files- I’ll cover this in a future post.

To further minimize the risk of a hash collision, websites often store hashes off a password + a salt. The “salt” is simply a few extra characters added to your password.

Adding something like +7623&" at the end of the password reduces the risk of issues if two users have the same password. This also works to strengthen the hash against rainbow table attacks in which hackers generate large tables of precomputed hashes to compare with stolen databases.

If the hacker can find a match between the rainbow table and the stolen database then the hacker can easily derive the original password and simply log into the account.

Password Managers

The key point to take away is to create a strong password and use different passwords for all your accounts. The problem now is remembering all the different passwords. This is where a password manager comes in.

There are two main types of password managers.

1) On device managers - credentials are stored on the device - an attacker would have to compromise the device to access the credentials. The downside is that your passwords are not synced across all your devices.

2) Cloud-based managers - Credentials are stored in the cloud and can be synced to any device. Naturally, this is less secure but depending on the provider this can be a suitable option. LastPass a major cloud-based password manager was hacked- simply google to read about the story.

For those using IOS and want a secure on-device password manager - consider Spectre formerly known as M.Password. You create a username, master password to create an account. To add password entries, you can enter the name of your account provider or any other identifier, Spectre then generates a password using a “stateless algorithm”, passwords are not stored but calculated. The cool thing is that you can download the manager on any other device - simply input your username, master password, and account provider and your password will be calculated, no cloud storage necessary.

For those wanting a cloud-based manager consider The Bitwarden Password Manager. Bitwarden is open source, and Bitwarden encrypts, salts, and hashes your information for secure storage.

Happy Passwording.