Introduced in 1975 by Saltzer and Schroeder in their landmark paper The Protection of Information in Computer Systems, these timeless principles continue to guide secure system design today.

Secure design principles are aimed at protecting computer-stored information from unauthorized access. In this article, we’ll discuss these principles in detail, emphasizing their ongoing relevance in preventing security vulnerabilities. You’ll see some real-world examples that highlight the importance of adhering to these principles for creating robust, secure systems.

Saltzer and Schroeder outlined eight core principles along with two additional ones. These additional principles, while initially considered to apply imperfectly to computer systems, have since proven essential.

Let's start by outlining these secure design principles before delving deeper into each one.

Key Secure Design Principles:

1. Economy of mechanism: Keep designs simple and minimal.

2. Fail-safe defaults: Base access on permission, not exclusion.

3. Complete mediation: Check every access request for authority.

4. Open design: Secrets lie in data, not design.

5. Separation of privilege: Require two parties for critical decisions, it is safer.

6. Least privilege: Operate with the minimum necessary permissions.

7. Least common mechanism: Limit shared subsystems between users.

8. Psychological acceptability: Ensure usability for humans.

Additional principles:

9. Work factor: Weigh the cost of breaching security against the attacker's resources.

10. Compromise recording: Log breaches when they occur.

The Eight Main Secure Design Principles

Economy of Mechanism

The first principle instructs that you should keep your design simple and compact to minimize unwanted access paths.

Errors often go unnoticed during normal use, making it crucial to have straightforward designs that are easier to inspect for vulnerabilities. A simpler codebase reduces the attack surface, offering fewer opportunities for exploitation and facilitating code verification.

But remember that simplicity isn’t just a synonym for brevity. For instance, consider this C code:

// Example A 
if (a = b)  

// Example B 
a = b;   
if (a != 0)

Here, someone who looks at this code may think that the developer intended "==" instead of "=". The first example could lead to confusion, while the second clearly conveys the developer's intent. This may look trivial, but this confusion was key in an attempt to backdoor the Linux kernel in 2003!

Ultimately, it's tempting to write concise hacks that work, but they can become confusing, even to yourself in the future. Prioritize clean code and adhere to coding standards and best practices.

Fail-Safe Defaults

You should base access decisions on permission rather than exclusion. Mistakes in permission-based systems typically result in accidental denials – that is, users being denied access to necessary information. These can be quickly identified.

On the other hand, errors in exclusion-based systems may lead to unauthorized access. These can often go unnoticed, as people rarely report having unnecessary permissions.

In essence, you should prioritize allowlists over denylists – not just in access control, but also in input validation.

An allowlist (formerly known as a whitelist) specifies who can access what, denying everyone else by default. In contrast, a denylist (formerly known as a blacklist) allows all access except for specified exclusions. These are often implemented as rules, such as only allowing an integer value between 0 and 200, or a string that must match a regular expression before it can be accepted as an e-mail address.

Complete Mediation

This principle states that every access to every object must undergo an authority check. It ensures a comprehensive view of access control, encompassing all system operations, from initialization to recovery, shutdown, and maintenance.

It requires a reliable method for identifying the source of every request, and any changes in authority must be promptly updated. This principle also applies to input validation.

Complete mediation emphasizes that no access should rely on previous checks or assumptions of validity, reflecting the defense-in-depth approach. Each access request must be validated in real-time to prevent vulnerabilities, such as time-of-check to time-of-use (TOCTTOU) attacks.

Consider this scenario: You have two ATM cards linked to the same bank account. When you attempt to withdraw your funds at one ATM, it checks your balance and asks for confirmation. While waiting, you use the other ATM to withdraw the entire amount. If the first ATM didn't recheck your balance, you could exploit this to withdraw funds twice.

Fortunately, complete mediation ensures that the ATM verifies your balance again before dispensing cash, effectively preventing such exploitation.

Open Design

Design transparency is crucial. Security should not rely on the ignorance of potential attackers, but instead on well-protected keys or passwords. Maintaining secrecy in widely distributed systems is unrealistic.

The open design principle is grounded in Kerckhoff’s principle, which asserts that a cryptographic system's security relies solely on the secrecy of its keys, while the algorithm itself should be public knowledge.

In contrast, security by obscurity assumes safety through concealment, which is fundamentally flawed. Attackers can obtain design documents, reverse-engineer products, or exploit hidden vulnerabilities. Beyond that, keeping the implementation secret complicates security audits and reviews. Effective security design must never depend on keeping the implementation confidential.

Separation of Privilege

Using a dual-key system is generally more secure and adaptable than relying on a single key for access. A key principle of secure design is to implement multiple layers of protection. The more checks in place, the tougher it becomes for attackers.

But these checks should employ different mechanisms. For instance, in multi-factor authentication, combine knowledge-based methods (like a password) with either possession-based methods (like a token) or biometrics (like a fingerprint).

For added security, consider incorporating location data. If your credit card is used in London and then again in Moscow shortly after, your bank’s fraud detection will likely flag the second transaction. But it’s important to note that location data cannot substitute for any of the primary authentication factors.

This principle also implies the necessity of creating users with specialized roles and privileges instead of relying on superusers who can access everything.

Least Privilege

Every program and user should have only the minimum privileges needed to perform their tasks. Identify the specific capabilities a program needs and provide only those permissions. This approach significantly reduces the impact of potential attacks.

For instance, an image viewer shouldn’t require network access, and a bus timetable app shouldn’t access your call history or contacts. While implementing this can be challenging, the best strategy is to deny all permissions by default and grant them gradually as necessary.

Least Common Mechanism

Minimize shared mechanisms among users, as each shared component, especially those involving common variables, can create security risks. Any dependence between components can lead to widespread consequences if one is compromised.

Be cautious with shared code, as assumptions may change when the code interacts with different environments. For instance, the Ariane 5 rocket disaster resulted from reusing the Ariane 4 code without testing it with the new trajectory that had a much higher horizontal bias. This caused possibly the most expensive integer overflow in history.

Shared data poses similar risks. If two processes access the same temporary files, a compromise of one of the processes can affect the other. Process separation and isolation as well as utilizing techniques like containers and virtualization can help prevent the domino effect.

Psychological Acceptability

Design user interfaces for ease of use to ensure users apply security mechanisms correctly. When users' mental models align with the protection mechanisms, errors are minimized. If the authentication process is overly complicated, users may resist it or find ways around it.

Balancing security and usability can be challenging, as increasing one often decreases the other. Aim for a compromise where security measures are effective but still allow for a positive user experience.

The Two Additional Principles

Work Factor

Assess the cost of bypassing security mechanisms against an attacker's resources, known as the "work factor." While some work factors are straightforward to calculate, many computer security mechanisms defy easy assessment, making it challenging to gauge the risks accurately.

You should aim for a balance between security costs and potential losses, considering both the attacker’s motivations and the value of your assets.

For example, securing your car is usually sufficient if it’s harder to steal than your neighbor’s. But if your car is particularly desirable to thieves, you’ll need stronger security measures.

For a practical example, password storage algorithms – such as Argon2, bcrypt, and scrypt – have a ‘work factor’ parameter that determines the amount of resources to use. This can be scaled to keep the algorithm fast enough for regular use, but prohibitively expensive to brute-force.

Compromise Recording

This principle highlights the need for effective logging and evidence collection. If an attack goes unnoticed, the consequences can be severe, so detecting breaches promptly is vital for minimizing damage and facilitating incident response.

Wrapping Up

As Saltzer and Schroeder remind us, these principles serve as helpful warnings rather than strict rules. If you notice a principle being violated in your design, it’s a sign that something could be wrong and should be closely examined to ensure the issue is addressed or isn’t significant.

Remember, even the best-designed systems can be vulnerable if a single bug slips through during implementation. That’s why secure design and implementation must work together – security is a comprehensive approach. Most exploitable weaknesses come from either the design phase or the implementation phase, and attackers don’t care which type they exploit – they just want to break in.

The latest OWASP Top 10 emphasizes the critical role of design by featuring "Insecure Design" for the first time. To address this, it is essential for developer teams to understand best practices thoroughly.

Cydrill’s secure coding training program delves into these principles, offering real-world examples that demonstrate how neglecting them can lead to serious vulnerabilities. Check it out if you want to learn more.

This guide will explore the current state of authentication, delve into what passkeys are, how they work, and discuss the challenges and future of this technology.

The Current State of Authentication

Authentication is a critical component of digital security, serving as the gateway to systems and data. Despite numerous advancements, traditional authentication methods, such as passwords and social logins, remain prevalent. But these methods are increasingly proving to be inadequate in addressing modern security challenges.

Passwords, once considered the gold standard, are now recognized as a significant weak link in cybersecurity. The rise in sophisticated cyberattacks, coupled with poor password practices, has highlighted the urgent need for more robust authentication mechanisms.

Passwords are susceptible to various attacks, including phishing, brute force, and credential stuffing. Many users also recycle passwords across multiple sites, exacerbating the risk. Managing multiple passwords can be cumbersome, leading to weak password practices and forgotten credentials.

Social logins, while convenient, bring their own set of issues, including privacy concerns and dependency on third-party platforms. Users are often wary of sharing their social media credentials with third-party sites, fearing data misuse.

Also, social logins tie users to specific platforms, which can be problematic if a user decides to leave a social network or if the platform experiences an outage.

Magic links, an alternative authentication method, also have their limitations. Magic links are sent via email, which is not always secure. If an email account is compromised, so is the authentication.

The process of checking email and clicking a link can be cumbersome, particularly for users on mobile devices or with poor internet connectivity. Emails can also be delayed, end up in spam folders, or fail to deliver, causing frustration and potential access issues for users.

As the digital landscape continues to evolve, the need for more secure, user-friendly, and scalable authentication solutions becomes paramount. This exploration of the inherent problems with passwords, social logins, and magic links sets the stage for understanding why passkeys are a vital innovation in the field of authentication.

What are Passkeys?

Passkeys represent a modern authentication solution designed to address the shortcomings of traditional methods. Essentially, passkeys eliminate the need for passwords by utilizing a pair of cryptographic keys to authenticate users securely.

At the core of passkeys is public-private key cryptography. Each user has a unique pair of keys: a public key, which is stored on the server, and a private key, which remains securely on the user's device.

When a user attempts to authenticate, they use a method like biometric verification (fingerprint or facial recognition) or a device-specific security feature to access their private key.

This private key generates a cryptographic signature that the server verifies using the corresponding public key, ensuring a secure and seamless authentication process.

Diagram showing the passkey authentication process

Passkeys are built on the FIDO2 standard, which promotes interoperability and security across different devices and platforms. Major tech companies, including Google, Microsoft, Okta, and Apple, support this standard, making it a robust and widely adopted solution.

The use of biometrics and device-based authentication enhances security by ensuring that the private key never leaves the user's device and is never exposed to potential attackers.

This approach significantly reduces the risk of phishing attacks, as there are no passwords to be stolen or guessed. Passkeys also help streamline the user experience by eliminating the need to remember and manage multiple passwords.

Implementing passkeys involves a few key steps:

1. Registration: During account creation or passkey setup, the user's device generates a new key pair. The public key is sent to the server and stored with the user's account information.
2. Authentication: When the user logs in, they use their private key to generate a cryptographic signature. The server verifies this signature using the stored public key, ensuring that the user is who they claim to be.

Visit learnpasskeys.io to learn in detail how each of these processes work.

By leveraging these principles, passkeys offer a secure, user-friendly, and scalable solution for modern authentication needs. As developers, understanding how passkeys work and how to implement them is crucial in staying ahead in the realm of digital security.

Challenges with Passkeys

While passkeys offer numerous advantages over traditional authentication methods, they are not without their challenges. Understanding these challenges is crucial for developers and organizations considering adopting this technology.

Adoption and Integration

One of the primary challenges with passkeys is the integration with existing systems.

Many organizations rely on legacy systems that are not compatible with passkey technology, requiring significant overhauls to implement. Migrating to a passkey-based system involves not only technical adjustments but also changes in infrastructure, which can be resource-intensive and time-consuming.

User Education and Trust

Introducing a new authentication method requires educating users about how it works and why it's beneficial.

Users need to understand and trust the new system, which can be a hurdle given the novelty of passkeys. Ensuring that users feel comfortable and secure with the transition from passwords to passkeys is essential for widespread adoption.

Technical Considerations

Passkeys rely heavily on device capabilities. Not all devices support biometric authentication or the FIDO2 standard, potentially limiting the adoption of passkeys.

Developers need to ensure that fallback mechanisms are in place for users with unsupported devices, which can complicate the implementation process.

Compatibility and Interoperability

While the FIDO2 standard promotes interoperability, ensuring compatibility across different devices, operating systems, and browsers can still be challenging. Developers need to thoroughly test their implementations to ensure a seamless user experience across all platforms.

Despite these challenges, the benefits of passkeys in terms of security and user experience make them a compelling option for modern authentication. By addressing these challenges proactively, developers and organizations can pave the way for a more secure and user-friendly authentication future.

The Future of Authentication

The evolution of authentication is a testament to our ongoing quest for balance between security and convenience. From the simplicity of passwords to the robust security of passkeys, each step forward has been driven by the need to protect our digital lives against increasingly sophisticated threats.

Passkeys represent a significant leap in this journey, offering a secure, user-friendly alternative to traditional methods. By leveraging cryptographic keys and biometric verification, passkeys address many of the vulnerabilities that plague passwords and social logins.

The path to widespread adoption is not without its challenges, though, from integration hurdles to user education. But despite these obstacles, the benefits of passkeys make them a compelling option for modern authentication.

As developers and organizations navigate these challenges, the future of authentication looks promising. By embracing innovations like passkeys, we can move towards a more secure, seamless digital experience for all users.

The story of authentication is ongoing, and as we continue to innovate, the lessons from our past and the potential of our future guide us towards a safer digital world. Stay ahead of the curve, keep learning, and together, we can build a more secure digital landscape.

Thanks for reading!

Security is critical in the field of web development, particularly when dealing with user credentials such as passwords. One security procedure that's critical in web development is password hashing.

Password hashing guarantees that plaintext passwords are difficult for attackers to find, even in a situation where a database is compromised. But not all hashing methods are created equal, and this is where bcrypt stands out.

Node.js, a popular framework for developing web applications, provides a robust ecosystem for constructing secure authentication systems. In this article, we'll look at using bcrypt in Node.js to hash passwords. We'll look at how bcrypt may be smoothly incorporated into Node.js applications to improve security and safeguard user credentials effectively.

Whether you're an experienced Node.js developer looking to strengthen your authentication practices or a beginner looking to learn the best techniques for secure password management, this article will be helpful to you. Let's have a look at how you can use bcrypt to hash passwords in Node.js.

Here's what we'll cover:

1. What is Hashing?
2. What is Bcrypt?
3. How to Install Bcrypt in Nodejs
4. How to Set Up Bcrypt in Node.js
5. How to Hash Passwords With Bcrypt
6. How to Verify Passwords With Bcrypt
7. Security Best Practices with Bcrypt
8. Conclusion

What is Hashing?

Hashing involves converting a given key or string of characters into another value. This is typically represented by a shorter, fixed-length value or key that represents the original value and facilitates the retrieval.

What is Password Hashing?

Password Hashing is a process of converting an input password into a fixed-length string of characters, typically for the purpose of securely storing and transmitting the password.

Password hash functions are designed to be one-way functions. This means it should not be computationally possible to reverse the process and get the original input password from the hashed value.

For example, suppose we want to hash a password like "password123". The password will be transformed into a fixed-length character string using a hash algorithm like bcrypt. And we'll get a hashed result once the hash function has processed our password.

The hashed output of "password123" using bcrypt, for instance, would look like this:

e234dsdom3k2kmdl3l43iwes9vjro44223m3n32kn5n2ksdo4

Now that you understand the basics of how password hashing works, it's time to dive deeper into the practical application of hashing a password using the bcrypt algorithm.

But before we proceed with that, let's learn a bit more about bcrypt so you understand its workings and installation process, as well as how to integrate it into a Node.js project.

Firstly, let's gain insight into bcrypt – what it is, how it operates, and its significance in password security. Then we'll discuss how to install bcrypt and integrate it seamlessly within a Node.js environment. This will include a detailed walkthrough on setting up bcrypt within your project and leveraging its functionalities effectively.

By the end of this article, you'll have a comprehensive understanding of bcrypt, equipped with the knowledge to securely hash passwords in your Node.js applications. So, let's embark on this journey to enhance the security of our projects through bcrypt integration.

What is bcrypt?

bcrypt is a type of cryptographic algorithm used to securely store passwords. It scrambles a user's password into a unique code. This way, even if a thief takes the database, they won't be able to recover the original passwords readily.

How Does bcrypt Work?

bcrypt works by combining hashing and a technique known as salting, which is specifically developed to make stored passwords more safe.

Here's a breakdown of the procedure:

1. Hashing: Bcrypt processes a user's password using a sophisticated mathematical function. This function converts the password to a fixed-length string of characters that appear random and meaningless. The hashed value is what is kept in the database, not the original password. Because the hashing function is one-way, reversing the hash will not produce the original password.
2. Salting: To improve security, bcrypt incorporates a random number called a salt. This salt is unique to each password and is attached to it before hashing. The combined value (password + salt) is then passed to the hashing function.

How to Install Bcrypt in Nodejs

Before you install bcrypt, you'll need to have a Node.js project already set up. If you haven't created one yet, follow these steps to create a new Node.js project:

Create a directory:

This command creates a new directory (folder) where your Node.js project will reside. It's named bcrypt-password-hash.

mkdir bcrypt-password-hash

• mkdir: This command stands for "make directory." It's used to create a new directory.
• bcrypt-password-hash: This is the name of the directory you're creating. You can choose any name you prefer for your project directory.

Change into the newly created directory:

This command navigates you into the newly created directory so that you can start working on your project within it.

cd bcrypt-password-hash

• cd: This command stands for "change directory." It's used to move from one directory to another.
• bcrypt-password-hash: This is the name of the directory you want to navigate into.

Initialize a new Node.js project:

This command initializes a new Node.js project within the directory you created. It creates a package.json file, which is used to manage dependencies and configuration for your Node.js project.

npm init -y

• npm init: This command initializes a new Node.js project using npm (Node Package Manager).
• -y: This flag automatically accepts all default values for the package.json file, so you don't have to manually provide input for each field.

After running these commands, you should have a new directory (bcrypt-password-hash) with a package.json file, indicating that you successfully created a new Node.js project. You can now go ahead and install dependencies and write code.

Create a file named index.js where you will write your code:

To create a file named index.js where you will write your code, you can use the touch command in your terminal. Here's how to do it:

touch index.js

• touch: This command is used to create a new file. (Note that you must have already installed touch on your machine to use it. If
  you haven't, you may run this command in your terminal to install
  touch: npm install touch-cli -g.)
• index.js: This is the name of the file you want to create. In this case, you're creating a JavaScript file named index.js.

After running this command, you'll have a new file named index.js in your project directory where you can write your Node.js code just like you can see in the image below:

Now that we've correctly constructed a Node.js project, we can install bcrypt in our project.

Install the required dependencies (bcrypt):

To install bcrypt, you'll use npm, the Node.js package manager. Here's the command to install bcrypt:

npm install bcrypt

• npm install: This command is used to install packages from the npm registry.
• bcrypt: This is the name of the package you want to install. bcrypt is a popular package for hashing passwords securely in Node.js.

When you run this command, npm will download and install the bcrypt package and its dependencies in the node_modules directory of your project. This directory will include all of the dependencies required for your project, including bcrypt.

How to Set Up Bcrypt in Node.js

Once Bcrypt is installed in your Node.js project, you can seamlessly integrate its functionality into your application. Here's how to proceed:

Firstly, after installing the bcrypt package using npm, make sure you import it into your Node.js application index.js file to utilize its features effectively.

Here's how to do it:

const bcrypt = require('bcrypt');

This line of code ensures that the bcrypt package is accessible within your application, allowing you to leverage its powerful capabilities for secure password hashing and verification.

With bcrypt integrated into your project, you can enhance the security of user authentication and data protection.

bcrypt provides two primary functions for password hashing and comparison:

1. bcrypt.hash(): This function is used to generate a hash of a plaintext password. It takes the plaintext password and a salt factor (optional) as input parameters and returns the hashed password asynchronously.
2. bcrypt.compare(): This function is used to compare a plaintext password with its hashed counterpart. It takes the plaintext password and the hashed password as input parameters and returns a boolean value indicating whether the passwords match.

How to Hash Passwords With Bcrypt

Having delved into the significance of password hashing, as well as the concepts of hash and salt, let's put theory into practice within our index.js file.

How to Generate a Salt and Hash the Password

As we've learned, a key aspect of secure password hashing involves incorporating a unique salt into the hashing process. bcrypt simplifies this by handling salt generation and password hashing seamlessly.

To begin, we require the bcrypt module in our Node.js application:

const bcrypt = require('bcrypt');

To ensure the strength of our password hashes, we determine the number of salt rounds. This value dictates the computational cost of hashing and, consequently, the level of security:

const saltRounds = 10; // Typically a value between 10 and 12

With our configuration established, we can generate a salt asynchronously using the bcrypt.genSalt() function. This salt will be unique for each password hash, enhancing security:

bcrypt.genSalt(saltRounds, (err, salt) => {
if (err) {
    // Handle error
    return;
}

// Salt generation successful, proceed to hash the password
});

Once the salt is generated, we combine it with the user's password to compute the hash using the bcrypt.hash() function. This results in a securely hashed password ready for storage:

const userPassword = 'user_password'; // Replace with the actual password
bcrypt.hash(userPassword, salt, (err, hash) => {
    if (err) {
        // Handle error
        return;
    }

// Hashing successful, 'hash' contains the hashed password
console.log('Hashed password:', hash);
});

By leveraging bcrypt for password hashing in our Node.js application, we ensure the robust security of user credentials. The incorporation of unique salts for each password hash, coupled with the computational complexity of bcrypt, fortifies our defense against unauthorized access and malicious attacks.

In the next section, we'll explore how to verify passwords and discuss best practices for securely managing hashed passwords.

How to Verify Passwords With Bcrypt

Now that we've covered the process of hashing passwords using bcrypt within our Node.js application, let's shift our focus to verifying passwords during user authentication.

In this section, we'll explore how bcrypt facilitates password verification, ensuring a secure and seamless authentication process.

How to Retrieve a Hashed Password from the Database

Before we can verify a user's password, we need to retrieve the hashed password associated with the user's account from the database.

Assuming you have a user authentication system in place, you'll typically query the database to fetch the hashed password based on the user's username or email.

Once you have retrieved the hashed password from the database, you're ready to proceed with the password verification process.

How to Verify Passwords

To verify a password using bcrypt, use the bcrypt.compare() function. This function compares a plaintext password provided by the user during login with the hashed password stored in the database.

Here's how you can implement password verification using bcrypt in your Node.js application:

const storedHashedPassword = 'hashed_password_from_database';
const userInputPassword = 'password_attempt_from_user';

bcrypt.compare(userInputPassword, storedHashedPassword, (err, result) => {
    if (err) {
        // Handle error
        console.error('Error comparing passwords:', err);
        return;
    }

if (result) {
    // Passwords match, authentication successful
    console.log('Passwords match! User authenticated.');
} else {
    // Passwords don't match, authentication failed
    console.log('Passwords do not match! Authentication failed.');
}
});

In this code snippet, storedHashedPassword represents the hashed password retrieved from the database, while userInputPassword is the plaintext password provided by the user during login. The bcrypt.compare() function compares these two passwords and returns a boolean value indicating whether they match.

In the next section, we'll discuss best practices for securely managing hashed passwords, including considerations for password storage and handling.

Security Best Practices with bcrypt

Now that we've discussed the principles of password hashing and verification with bcrypt, let's look at some important security best practices to ensure the integrity of our authentication system.

Robust Password Guidelines

Encourage users to create strong and complex passwords that are resistant to dictionary attacks. Provide guidance on password length, the inclusion of alphanumeric characters, symbols, and the avoidance of common patterns.

Salting

Always use a unique salt for each password hash. This prevents attackers from using precomputed rainbow tables to crack passwords. bcrypt automatically handles salt generation, ensuring that each hash is unique.

Adaptive Hashing

bcrypt employs adaptive hashing, allowing developers to adjust the computational cost of hashing over time. Periodically increase the number of hashing rounds to keep pace with advancements in hardware and computational power.

Secure Storage

Store hashed passwords securely in your database. Ensure that access controls are in place to prevent unauthorized access to user credentials. Avoid storing plaintext passwords or using reversible encryption algorithms.

Error Handling

Implement proper error handling mechanisms when working with bcrypt functions. Handle errors gracefully and avoid leaking sensitive information that could aid attackers in exploiting vulnerabilities.

Conclusion

In conclusion, we have explored the essential aspects of password security and the role of bcrypt in safeguarding user credentials within Node.js applications. From understanding the fundamentals of password hashing and salting to implementing secure authentication mechanisms, we have covered a wide array of topics aimed at enhancing the security posture of our applications.

By leveraging bcrypt for password hashing and verification, we ensure that sensitive user data remains protected against unauthorized access and malicious attacks. bcrypt's robust algorithm, combined with adaptive hashing and salt generation, provides a reliable defense mechanism against common password-based vulnerabilities.

We also discussed security best practices, including strong password policies, secure storage practices, and error handling. By adhering to these best practices and staying vigilant against evolving threats, we can create a secure authentication system that instills confidence in our users and upholds the integrity of our applications.

Let's continue to prioritize security and strive for excellence in our pursuit of building robust and trustworthy applications.

Thank you for joining me on this exploration of password security with bcrypt. Together, we can create a safer digital environment for all users.

Happy Coding!

It has the potential to reshape everything in data privacy and security.

What really is homomorphic encryption? Why is it getting so much attention? How can it increase data privacy?

Essentially, with homomorphic encryption, we can process encrypted data without ever needing to decrypt it for computation.

This results in complete privacy everywhere the data is processed and stored.

In this article, you'll learn why this type of encryption will revolutionize the field of security. We'll tackle questions such as:

• What is homomorphic encryption?
• How does homomorphic encryption work?
• Homomorphic encryption vs traditional encryption – what's the difference?
• What are the applications of homomorphic encryption?

What is Homomorphic Encryption?

Let's use an analogy to understand homomorphic encryption.

Imagine a locked treasure chest that has many valuable items inside.

To add or remove items, you need to unlock the chest. This could make it easier for thieves to steal the items when you open it.

In this analogy, this is what traditional encryption is.

Homomorphic encryption is like having a magical glove that allows you to add or remove items from the chest without ever unlocking it.

This way, you remove the risk of thieves ever getting the items inside the treasure chest.

This is essentially what Homomorphic encryption does with data: it allows us to perform operations on encrypted data without ever needing to decrypt it.

This is not possible with traditional encryption. In that case, we must process the data we need to decrypt, do whatever computations are necessary, and then encrypt the data again.

With homomorphic encryption, security is never compromised.

How Does Homomorphic Encryption Work?

Homomorphic encryption allows computations to act on encrypted data – also called ciphertext.

This means the data is processed while encrypted.

Homomorphic encryption does computations on encrypted data (ciphertext). But computations done in ciphertext give encrypted results.

When these results are decrypted, they are similar to those that would've been obtained if the operations had been performed on the original, unencrypted data.

So basically, homomorphic encryption allows operations on encrypted data to give the same results as if performed on the original, decrypted data.

How is this done?

Homomorphic encryption uses complex mathematical algorithms that:

• transform the numbers to obscure the original data, and
• perform the same operations whether on the original or on this obscured data.

Essentially, you're always working on the same data in the same way, but from different points of view.

So you can work with the data and get exactly the same results as if it were not encrypted. But since it actually is encrypted, the data is always protected!

This way, no one can see it and maybe steal it, which allows data privacy even in environments where trust is minimal.

Python code example

We are going to use the Pyfhel library for this example, which you can read more about here.

In this code, we are going to add two numbers in their encrypted form and see the results.

Here is the full code so you can truly understand how homomorphic encryption works:

import numpy as np
from Pyfhel import Pyfhel

HE = Pyfhel()
HE.contextGen(scheme='bfv', n=2**14, t_bits=20)
HE.keyGen()

integer1 = np.array([127], dtype=np.int64)
integer2 = np.array([-57], dtype=np.int64)

ctxt1 = HE.encryptInt(integer1)
ctxt2 = HE.encryptInt(integer2)

ctxtSum = ctxt1 + ctxt2
ctxtSub = ctxt1 - ctxt2
ctxtMul = ctxt1 * ctxt2

resSum = HE.decryptInt(ctxtSum) 
resSub = HE.decryptInt(ctxtSub)
resMul = HE.decryptInt(ctxtMul)

Now we are going to break it down line by line:

First, we need to import the necessary modules:

import numpy as np
from Pyfhel import Pyfhel

Here, we are just importing the necessary modules to make our calculations.

Next, we need to create a Pyfhel object and generate keys:

HE = Pyfhel()
HE.contextGen(scheme='bfv', n=2**14, t_bits=20)
HE.keyGen()

In the first line we initialize a Pyfhel python object. In the second line we set encryption with certain parameters:

• scheme='bfv': We use the BFV (Brakerski/Fan-Vercauteren) homomorphic encryption scheme.
• n=2**14: Defines the degree of the polynomial modulus degree. The polynomial modulus degree balances the encryption security level with the computational efficiency. A bigger number gives better encryption but at the cost of more computational resources
• t_bits=20: Sets the bit size of the plaintext modulus. Bigger bit size values let you use larger numbers but make the encryption less clean
• In the third line, we generate a public and private key

Then, we get two numbers and encrypt them:

integer1 = np.array([127], dtype=np.int64)
integer2 = np.array([-57], dtype=np.int64)

ctxt1 = HE.encryptInt(integer1)
ctxt2 = HE.encryptInt(integer2)

We represent the numbers in a array with just one number and encrypt them.

We represent these numbers in an array and not as if we are declaring variables.

We do this because the function encryptInt() only takes an array of integers with 64 bits as an argument. From the documentation:

encryptInt(self, int64_t[:] arr, PyCtxt ctxt=None)

Now we'll perform the operations on the two numbers while encrypted:

ctxtSum = ctxt1 + ctxt2
ctxtSub = ctxt1 - ctxt2
ctxtMul = ctxt1 * ctxt2

And then decrypt the numbers after the operation when they where encrypted:

resSum = HE.decryptInt(ctxtSum) 
resSub = HE.decryptInt(ctxtSub)
resMul = HE.decryptInt(ctxtMul)

Which will output the following:

>>> [70  0  0 ...  0  0  0]
>>> [184   0   0 ...   0   0   0]
>>> [-7239     0     0 ...     0     0     0]

And if we do the normal calculations without being encrypted, we see that the values match:

integer1 = 127
integer2 = -57

print(integer1+integer2)

print(integer1-integer2)

print(integer1*integer2)

Which gives the following:

>>> 70

>>> 184

>>> -7239

As you can see, we get the same results if we perform the operations on the data while it's encrypted as we do when it's not encrypted.

Homomorphic Encryption vs Traditional Encryption – What's the Difference?

In traditional encryption methods, data needs to be decrypted before any kind of processing.

In homomorphic encryption, data is always used in its encrypted state.

Traditional encryption is like a secure envelope: contents must be taken out to be read or modified.

Homomorphic encryption is like a special envelope that allows content manipulation without ever needing to open it to be read or modified.

Applications of Homomorphic Encryption

There are many practical applications of homomorphic encryption.

In cloud computing, it allows users to process data in the cloud without ever exposing it to cloud service providers. This way, sensitive information always remains confidential.

In healthcare, it allows the analysis of encrypted medical records without compromising patient privacy. Patient health data always remains protected.

Another promising application of homomorphic encryption is in secure voting systems. Using this type of encryption, votes are counted in such a way that no one can see for whom each person voted. This would make the voting process safer and more private.

These examples represent just the tip of the iceberg.

Conclusion

Homomorphic encryption is a paradigm shift in how we handle and process sensitive data.

This technology and its development are important as more and more data breaches are happening all the time.

Homomorphic encryption offers a path toward the simplification of data privacy regulations.

It also allows more innovation by making the protection of private data simpler, encouraging new security developments.

In this walkthrough, you'll first learn what Server-Side Request Forgery is and how it differs from Client-Side Request Forgery. We will create a sample application to gain a better understanding of how Server-Side Request Forgery attacks work, and explore various methods to safeguard our application against SSRF vulnerabilities.

Table of Contents:

• Prerequisites

• What is Server-Side Request Forgery?

• How Does SSRF Differ from CSRF?

• Identifying Code Smells

• Understanding the Pain Points

• Project Setup

• How to Exploit the Vulnerability

• How to Defend Against SSRF Attacks

• Wrapping Up

Prerequisites

1. Node and Express: We'll create a JavaScript sample application using the Express framework. A basic understanding of the framework would be helpful. You will need the Node Runtime Environment to execute the scripts.

2. Postman Client: To make an API request and to exploit the vulnerability, you will need a tool to make HTTP Requests. You may use your web browser's "Edit and Send" feature under the Networks tab, but since not all browsers allow this, it's best to use a tool like Postman which provides a better UI to observe responses.

What is Server-Side Request Forgery?

Server-Side Request Forgery, or SSRF, is a security vulnerability that allows malicious actors to manipulate the server into making unintended requests on behalf of the server itself.

SSRF provides a window for such malicious actors to make requests "from" the server when they should be making requests "to" the server.

To appreciate what this means, let's look at a normal request execution using the sequence diagrams below:

UML Sequence Diagram for normal request execution

In a typical scenario, a server processes incoming requests from clients. Users or external systems initiate these requests, and the server responds accordingly. This is a standard client-server interaction where the server acts upon the requests it receives.

Now let's look at what SSRF looks like:

UML Sequence Diagram for SSRF attacks

In applications vulnerable to SSRF, attackers exploit the server's ability to make HTTP requests to resources that should not be directly accessible from the public internet. These resources may include internal protected resources, APIs, websites, or databases that can only be accessed from the server.

Attackers achieve this by tricking the server into making unintended requests to various destinations, including internal APIs, internal HTML pages, and internal databases.

How Does SSRF Differ from CSRF?

SSRF is an attack where an attacker can make the server perform requests on their behalf. This involves manipulating the server to make requests to internal resources, which can result in unauthorized actions or information disclosure.

On the other hand, in CSRF, or Client-Side Request Forgery, the attacker tricks a user's browser into making unintended requests to a specific web application for which the user is already authenticated. This means that actions are performed on behalf of the user without their consent.

Backend Developers must be aware of SSRF to make secure applications. In contrast, front-end developers must be mindful of and implement client-side security measures to prevent CSRF attacks.

Identifying Code Smells

SSRF attacks often occur when web applications improperly mishandle user-controlled input, leading to network requests based on inadequately sanitized user input. Processing un-sanitized URLs in API requests is a common entry point for SSRF attacks.

Another common giveaway to identifying SSRF vulnerabilities in your applications is to check for instances where XML parsing occurs without adequate validation of external entities. Applications that fail to validate and secure their XML parsers properly may inadvertently expose themselves to SSRF risks.

In this walkthrough, you will make a server that takes a URL and uses it to make network requests without proper validation and sanitization. You will then see ways to mitigate this issue.

Understanding the Pain Points

To better understand the issue of SSRF attacks, lets create a sample application using Express and JavaScript. Below is a Mermaid Sequence Diagram where we explain what the code base does:

UML Sequence Diagram for the sample application

We will create an Express app with two endpoints — /fetch, a GET request designed to fetch content from a specified URL, and /admin, another GET request, which is an internal API within the organization that accesses an internally protected resource.

We will discover a security vulnerability associated with Server-Side Request Forgery (SSRF) in implementing the first GET request.

We will also create another helper function at the /uploads endpoint to allow our clients to fetch and view their recently uploaded content.

Project Setup

To get started, let's quickly set up our repository and install all the required packages. In the root of your workspace, install Express and Axios using the following command:

npm init -y | npm i axios express

Executing this command will create a package.json file with default settings and install the specified packages.

To simulate the internal protected resource, let's create a data.json in the root of your workspace:

{   
    "name": "Hamdaan Ali Quatil",
    "password": "violinblackeye"
}

Now, create a file called app.js in the root of your repository. Here, we will define all of our endpoints. Import all required packages like this:

const express = require('express');
const axios = require('axios');
const fs = require('fs').promises;

We use the fs (File System) module to interact with the local file system. Within the Express application, we use fs.promises to read the contents of a file. The fetchPrivateResource function asynchronously reads the contents of the data.json file, which is an internal resource.

Let's create an instance of the Express app to handle HTTP requests and define the fetchPrivateResource method. In the sample application, only the admin should be able to fetch this internal resource, but you will observe how a malicious actor can access this using an SSRF attack.

const app = express();
const port = 3000;

// Function to fetch private resource
const fetchPrivateResource = async () => {
  try {
    const content = await fs.readFile('data.json', 'utf-8');
    return content;
  } catch (error) {
    console.error('Error reading private resource:', error.message);
    throw error;
  }
};

The Fetch Endpoint

Now, let's define our first endpoint, /fetch which expects a query parameter url containing the target URL. Upon receiving a request, the server uses the Axios library to make a GET request to the specified URL.

app.get("/fetch", async (req, res) => {
  const url = req.query.url;

  try {
    const response = await axios.get(url);
    const responseData = JSON.stringify(response.data);

    const filename = path.basename(url);
    const textFilePath = path.join(__dirname, "uploads", "upload-data.txt");

    await fs.writeFile(textFilePath, responseData, "utf-8");

    res.send("Upload Successful");
  } catch (error) {
    console.error("Error:", error.message);
    res.status(500).send("Internal Server Error");
  }
});

The axios.get method is used to perform the HTTP GET request, and the response data is then converted to a JSON string. The resulting string is written to a text file named upload-data.txt in the uploads folder of the server. Finally, a success message or an error message is sent back to the client, depending on the outcome of the operation.

The Uploads Endpoint

With that done, let's create an endpoint to allow users to access and verify their uploaded files. The server will check if the requested file exists, and if so, it sends the file to the client. When a file cannot be found, the server returns a 404 error.

app.get("/uploads/:filename", async (req, res) => {
  const filename = req.params.filename;
  const filePath = path.join(__dirname, "uploads", filename);
  console.log(filePath);

  try {
    // Check if file exists
    await fs.access(filePath);

    // If file exists, send it to the client
    res.sendFile(filePath);

  } catch (error) {
    res.status(404).send("File not found: " + error);
  }
});

The Admin Endpoint

Now, we need to make an internal API – the /admin route – which is intentionally shielded from public access. The objective is to ensure this API is only accessible from localhost or the local machine (127.0.0.1).

We can do this by implementing a middleware that acts as a protective barrier, permitting requests to proceed to the /admin route only if they originate from the local host.

The middleware checks whether the req.hostname property, which represents the hostname specified in the HTTP request, matches localhost or 127.0.0.1. If the request is from a different host, the middleware responds with a 403 Forbidden status, thereby restricting access.

// middleware to protect admin API
app.use('/admin', async (req, res, next) => {
  const isLocalhost = req.hostname === 'localhost' || req.hostname === '127.0.0.1';

  if (isLocalhost) {
    next();
  } else {
    res.status(403).send('Forbidden');
  }
});

// Route to access the admin API
app.get('/admin', async (req, res) => {
  try {
    const content = await fetchPrivateResource();
    res.send(content);
  } catch (error) {
    res.status(500).send('Internal Server Error');
  }
});

Once all routes are configured, we start the server using the app.listen method, and it begins listening on port 3000 for incoming requests.

app.listen(port, () => {
  console.log(`Server is running on http://localhost:${port}`);
});

With our app.js now set up to process incoming requests, let's run the sample application using nodemon:

npm i -D nodemon | nodemon app.js

The server has started on the port 3000. Now, we are ready to test our sample application and look for code smells that may lead to SSRF attacks. You may find the complete code here — GitHub Gist | HamdaanAliQuatil.

How to Exploit the Vulnerability

Let's try to make a GET request to the fetch API. We are simulating the process of uploading a text file using the URL to the file. In this demonstration, we will fetch the contents of an example file and save it on our servers. Here is the link to the text file.

Open your Postman Client and execute a GET request with the URL http://localhost:3000/fetch?url=https://example-files.online-convert.com/document/txt/example.txt. We are adding the link to the file as a Query Parameter in the /fetch endpoint. When you hit send, you will see a response "Upload Successful".

Postman Client: Fetch Endpoint

You'll see that your repository now has a newly created file in the uploads directory. Clients can now access their uploaded information using the /uploads API endpoint to view their files.

Postman Client: Uploads Endpoint

Now, let's send a malicious request by changing our Query param to http://120.0.07/admin in the same request to the /fetch endpoint. The updated URL will now look like this: http://localhost:3000/fetch?url=http://127.0.0.1:3000/admin.

In the Query parameter, 127.0.0.1 is a Loopback Address. A loopback address is a reserved IP address used to establish network connections with the same host (the local machine) for testing and communication within the device.

The malicious actor is attempting is to make a request to the server's /admin route from the server itself using the loopback address. This simulates an internal resource access scenario.

Postman Client: Admin Endpoint

You'll notice that an "Upload Successful" message comes as a response to this request. Now try accessing your uploaded file again using the GET request at the /upload endpoint.

Postman Client: Uploads Endpoint

You'll see that the contents of the uploaded file have been altered. This alteration highlights a successful SSRF (Server-Side Request Forgery) attack, where a malicious actor took advantage of the server's capability to initiate internal requests.

The file, which initially contained specific data, has now been tampered with. This showcases the potential for unauthorized access and manipulation of sensitive information through SSRF exploits.

How to Defend Against SSRF Attacks

Now, let’s see the ways in which we can fix our application's vulnerability to SSRF. The most intuitive solution that comes to your mind could be to never allow a client to enter a URL. This is certainly the most powerful defense. The server should create a URL it needs.

But many times, allowing URLs in your business logic becomes an absolute necessity. In such cases, our goal is to prevent the attack or at least reduce the risk if an attack occurs.

If you really must allow a URL as it is, here are some precautionary steps you can take:

Sanitization and Validation

As with most vulnerabilities, a pain-point in SSRF attacks is the use of untrusted data. Always treat any data coming from the client side as untrusted.

Sanitizing and validating the client-supplied data should go a long way to defend against SSRF attacks. A very intuitive validation is to restrict any URL containing localhost or the loopback address.

Let's create a helper function isValidUrl and call it in the function for the /fetch endpoint.

function isValidUrl(url) {
  // Restrict URLs to HTTP only. This blocks FTP and other protocols
  const validUrlRegex = /^http:\/\/\S+$/;

  if (!validUrlRegex.test(url)) {
    return false;
  }

  try {
    const parsedUrl = new URL(url);

    // Check if the host is localhost or a loopback IP address
    const isLocalhost = parsedUrl.hostname === 'localhost';
    const isLocalIP = /^127\.\d+\.\d+\.\d+$/g.test(parsedUrl.hostname);

    return !(isLocalhost || isLocalIP);
  } catch (error) {
    return false;
  }
}

Your updated function for /fetch endpoint should look like this:

app.get("/fetch", async (req, res) => {
  const url = req.query.url;

  if (!isValidUrl(url)) {
    res.status(400).send("Loopback URLs are not allowed");
    return;
  }

  try {
    ...
    res.send("Upload Successful");
  } catch (error) {
    ...
  }
});

Now, go back to the Postman Client and resend the malicious request. You will observe that previously uploaded file is not tampered and you receive "Loopback URLs are not allowed" in the response.

Whitelisting via an Allow List

You may create a positive allow list to only allow certain trusted IP Addresses, URL Schema, and Port. Let's implement an allow list and improve our isValidUrl function:

const whitelist = ["boost.com", "boost.in", "trustedDomain3.com"];
const allowedPorts = ['80', '443'];

Now use your declared whitelist in the isValidUrl function:

function isValidUrl(url) {
  try {
    const parsedUrl = new URL(url);

    if (!whitelist.includes(parsedUrl.hostname)) {
      return false;
    }

    if (!allowedPorts.includes(parsedUrl.port)) {
      return false;
    }

    return true;
  } catch (error) {
    return false;
  }
}

Notice how we've removed the need for regex. This brings us to another mitigation technique that you must avoid:

Don't Use a Deny List

You must never mitigate SSRF vulnerabilities using a deny list or regex. Restricting the use of IP Addresses is not straightforward. To understand why we must avoid a deny list, look at the following example.

A Loopback Address is typically represented using 127.0.0.1 . Its quite easy to spot this address and reject it. But a problem arises when a malicious request is sent using any other forms of this Loopback address that also points to the local machine. For example, 127.1, ::1, localhost ,::ffff:7f00:1 all point to the local machine.

A regular expression to spot all such variations is much more complex. Malicious actors can easily bypass a deny list by passing an octal representation of decimal encoding of the IP address.

Enforce a URL Scheme

In absence of this measure, a client might send requests that use any protocols other than the intended ones. To replace our validUrlRegex, we will use a allowedSchemes list. We will restrict our application to only process requests when the protocols are either https: or http. Not allowing any requests with protocols file: and ftp: will safe-guard our sample application.

const allowedSchemes = ['http:', 'https:'];

The updated isValidUrl function will look like this:

function isValidUrl(url) {
  try {
    const parsedUrl = new URL(url);

    if (!whitelist.includes(parsedUrl.hostname)) {
      return false;
    }

    if (!allowedPorts.includes(parsedUrl.port)) {
      return false;
    }

    if (!allowedSchemes.includes(parsedUrl.protocol)) {
      return false;
    }

    return true;
  } catch (error) {
    return false;
  }
}

Disable Redirects

Redirects are a mechanism used by web applications to forward a user's browser from one URL to another. If a server follows redirects automatically, an attacker could exploit this behavior to make the server inadvertently access internal resources, leading to data exposure or unauthorized actions.

To restrict redirects in Axios, pass in an Axios Configuration object in the second parameter:

const response = await axios.get(url, { maxRedirects: 0 });

To learn more about Axios Config, check this guide: Axios | Request Config.

Send Filtered Data to the Client

Avoid sending raw response bodies directly from your server to the client. Ensure that the responses reaching the client are carefully curated and conform to expected formats.

By implementing this practice, you shield your application from potential security vulnerabilities associated with exposing unfiltered or sensitive information. Always validate, filter, and format responses to align with your application's anticipated data structures.

Wrapping Up

And there you have it: by implementing a few well-established methodologies and best practices, you can effectively detect and mitigate SSRF attacks in your applications and create secure APIs as developers.

Find the complete code snippets here — GitHub Gist | HamdaanAliQuatil.
You may find me on X (formerly Twitter) - Hamdaan Ali Quatil.

In today’s digital world, where we rely on computers, smartphones, and the internet for almost everything, the importance of cybersecurity cannot be overstated.

While you might be familiar with the term “cyberattack,” there’s a lesser-known but equally crucial field that operates in the shadows — cybersecurity forensics. This is where the art and science of investigating digital crimes and breaches come into play.

What is Cybersecurity Forensics?

Cybersecurity forensics, in simple terms, is like being a digital detective. It involves the careful and systematic process of collecting, analyzing, and preserving digital evidence to uncover what happened in a cybercrime or security breach.

Imagine a digital crime scene where there are no physical fingerprints or footprints. Instead, there are digital footprints left behind on computers, smartphones, servers, and networks.

These footprints can be tricky to spot, but they are crucial in solving digital mysteries.

Types of Digital Evidence

Digital evidence comes in various forms, much like pieces of a puzzle. It includes things like compromised passwords, malware artefacts and network logs.

Compromised Passwords

When an unauthorized individual attempts to gain access to your account by guessing your password or through hacking techniques, it is known as a compromised password. Such attempts often leave behind evidence that can be scrutinized for increased security.

It includes multiple failed login attempts from unfamiliar locations or devices, changes made to the account settings, or even unauthorized transactions.

By looking for these signs, you can take immediate action, such as updating your password or enabling two-factor authentication, to secure your account and minimize potential damage.

Malware Artifacts

Malware, including viruses and malicious software, pose a significant risk to your computer system.

When a system is infected, malware often leaves behind traces known as artifacts. These artifacts include unusual files, changes in system settings, or the installation of new, unfamiliar software.

Recognizing these artifacts is important for removing the existing malware and improving the system's defence against future attacks. Specialized software tools can help identify and eliminate these threats, and help restore the system to a secure state.

Network Logs

Networks, whether they belong to an organization or an individual, maintain logs that record various activities occurring on the network.

These logs help in identifying suspicious activities, such as multiple login attempts from foreign IP addresses, the transfer of unusually large amounts of data, or unauthorized attempts to access private areas of the network.

By regularly reviewing and monitoring network logs, you can spot anomalies and take preemptive measures to counter any potential security threats.

The tricky part about digital evidence is that it can be easily tampered with or deleted, just like erasing a message from your phone. Preserving the integrity of this evidence is a top priority in cybersecurity forensics.

The Digital Detective’s Toolkit

To solve digital mysteries, cybersecurity forensic experts use a range of tools and techniques.

Forensic Software

In cybersecurity forensics, specialized software plays an important role in collecting and analyzing digital evidence. The use of such software helps to acquire and analyze data without causing any alterations.

This is crucial for maintaining the integrity of an investigation, especially if the findings are to be used in legal proceedings. By using forensic software, experts can carry out complex tasks such as data recovery, malware analysis, and encrypted file examinations.

Data Acquisition

Data acquisition involves creating an exact copy of the digital data in question. The importance of this process is its ability to preserve the integrity of the original data while providing investigators with a duplicate set for analysis.

This ensures that the original evidence remains untouched, thereby maintaining its credibility and usability in legal contexts. Methods like bit-by-bit copying are used to make sure that the duplicate is an exact replica, capturing not just files but also hidden or deleted information. It provides a comprehensive dataset for investigators to analyze while keeping the original data intact.

Chain of Custody

The concept of the chain of custody is equally important in cybersecurity investigations as it is in traditional detective work. It serves as a systematic documentation process that tracks how evidence is collected, stored, transferred, and eventually presented in court or other official settings.

Every individual who interacts with the evidence is identified, and their actions are carefully documented to prevent tampering or mishandling. This careful management ensures that the evidence remains reliable.

Maintaining an unbroken chain of custody is critical for upholding the integrity of the investigation and making sure that its findings are both credible and actionable.

The Investigative Process

Cybersecurity forensics investigations follow a structured process, just like detective work in the physical world. Here are the key steps:

• Data Collection: Experts collect digital evidence from various sources, such as computers, smartphones, or servers.
• Data Analysis: The collected evidence is carefully examined to understand what happened and who might be responsible.
• Reporting: Findings are documented in detailed reports, which can be used in legal proceedings if necessary.
• Presentation: Experts may need to present their findings to explain what they’ve discovered and how they reached their conclusions.
• Legal Considerations: Throughout the process, legal rules and standards must be followed to ensure the evidence is admissible in court.

The Future of Cybersecurity Forensics

The world of cybersecurity is constantly evolving, and so is the field of cybersecurity forensics. Here are some trends and challenges.

AI and Machine Learning

Artificial Intelligence (AI) and Machine Learning technologies are increasingly becoming valuable tools in the field of cybersecurity. They allow for the rapid detection and analysis of cyber threats, making it easier to identify vulnerabilities or potential attacks much faster than traditional methods.

By using algorithms that can learn from data, these technologies adapt and evolve, becoming more effective over time at identifying normal network behaviour from potentially harmful anomalies.

This heightened capacity for quick and accurate threat detection saves valuable time and resources, thus strengthening overall cybersecurity measures.

Encryption Challenges

As encryption technologies advance, they offer stronger protection for data, making it difficult for unauthorized users to access sensitive information.

This also presents challenges in cybersecurity forensics. Strong encryption can act as a barrier that makes it difficult for experts to uncover digital evidence during their investigations.

For example, if data is encrypted to a high standard, it could prevent the timely identification of malware or other cybersecurity threats. While encryption is essential for securing data, it also creates the need for more advanced tools and methodologies for cybersecurity professionals to penetrate these 'walls' and access the information they need to maintain security.

Emerging Cyber Threats

The cybersecurity landscape is continually evolving, with new types of threats appearing on a regular basis. This constant emergence of new threats presents a challenge for cybersecurity forensics experts, requiring them to stay updated and adapt their skills and tools continually.

From ransomware attacks that lock users out of their own systems to increasingly complicated phishing scams, these threats necessitate ongoing education and vigilance. By staying one step ahead, cybersecurity professionals can develop proactive measures and response strategies to neutralize these threats before they can inflict significant damage.

Conclusion

In a world where our lives have become increasingly digital, the work of cybersecurity forensics experts is more crucial than ever. They are the digital detectives who tirelessly investigate cybercrimes and breaches, ensuring that justice is served in the complex and rapidly changing world of cyberspace.

The art and science of cybersecurity forensics is essential in safeguarding our online lives and maintaining the trust and security of the digital realm.

If you found this article useful, visit Stealth Security to read more articles on ethical hacking. You can also connect with me on LinkedIn.

Web security is an important aspect of the web application development process. Especially as more data is stored, managed, and shared.

As a web developer, it's essential to prioritize security measures to protect your company’s users and data from potential threats.

In this article, I will demonstrate web security best practices by building a secure web application using Django, a powerful Python web framework. I'll cover password hashing, secure session management, authentication, authorization, and other key security considerations with accompanying code examples.

Before continuing with this article, keep in mind that this isn't intended for absolute beginners. You should have a good understanding of Python to get the most out of this guide.

If you need to brush up on your basic programming skills in Python and Django before continuing, here are a couple resources to help you out:

• Python for Everybody from Dr. Chuck
• Django for Everybody, also from Dr. Chuck

You will get access to the code at the end of the article.

Set Up Your File Structure

Let's say that we want to store our project on the desktop. The first thing do is to set up our file structure. Let's start by creating a root directory for our project on the desktop (WebSec in this case).

mkdir WebSec
cd WebSec

Create a Virtual Environment and Activate It

On Linux (Ubuntu):

python3 -m venv my_env

Source my_env/bin/activate

And on Windows:

python -m venv my_env

my_env\Scripts\activate.bat

How to Create the Django Project

First, if you don't already have it, you'll need to install Django using the following command:

python -m pip install Django

Then you can use this command to create the project:

django-admin startproject web_sec_project .

And finally, use this command to create the app:

django-admin startapp web_sec_app

Your file structure should look like this at the end:

WebSec
    my_env/
    web_sec_app/
        __pycache__/
        migrations/
        templates/
        admin.py
        apps.py
        forms.py
        models.py
        tests.py
        urls.py
        views.py
    web_sec_project/
        __pycache__/
        __init__.py
        asgi.py
        settings.py
        urls.py
        wsgi.py
    db.sqlite3
    manage.py

Run Your Server

On your IDE terminal run the following command and test if your project is working. If so, you are good to go.

python manage.py runserver

Ensure that you add your app to your project:

Check that your app is added

Now let’s start building and implementing web security.

Password Hashing

The first line of defense when implementing web security is ensuring that user passwords are properly protected. And instead of storing passwords in plaintext, it's a good idea to hash them. We'll use cryptographic hashing to safeguard sensitive user information.

Cryptographic hashing, also known as hash functions or hash algorithms, is a fundamental concept in cryptography and computer security. It involves taking an input (or "message") and transforming it into a fixed-size string of characters, which is typically a sequence of numbers and letters. This output is called the "hash value" or "hash code."

Django provides a secure password hashing mechanism by default, using the PBKDF2 algorithm with a SHA-256 hash.

Django uses a robust and secure password hashing mechanism to protect user passwords. This mechanism helps ensure that even if the database is compromised, attackers cannot easily retrieve users' plaintext passwords. Django's password hashing mechanism consists of PBKDF2.

PBKDF2 is a simple cryptographic key derivation function that is resistant to dictionary attacks and rainbow table attacks. It is based on iteratively deriving HMAC many times with some padding. This ensures that even if the database is compromised, the passwords remain unreadable.

To demonstrate this, we are going to create a new user with a hashed password and save the user with their hashed password in the database.

First, we import the User from the User model. Then, we import make_password. Here's the code to do that:

#web_sec_app/views.py

from django.contrib.auth.hashers import make_password
from django.contrib.auth.models import User

# Create User views here.
def UserView(request):
    users = User.objects.all()
    password = 'password'
    hashed_password = make_password(password)
    return render(request, 'create_user.html', 
                {'users': users, 'hashed_password': hashed_password})

Secure Session Management

Session management is key to maintaining user state across multiple requests. Django comes with a built-in session management system that stores session data on the server-side. We'll ensure that the session data is encrypted and the session ID is secure to prevent session hijacking attacks.

To achieve secure session management, we will make sure we have a secure session cookie, which will require HTTPS. We are also going to prevent JavaScript access to the session cookie. The session expires when the browser is closed.

SESSION_COOKIE_SECURE = True

This setting tells Django to only send the session cookie over HTTPS connections. When set to True, the session cookie will not be sent over unencrypted HTTP connections. This is important for protecting sensitive session data, such as user authentication tokens, from being intercepted by malicious actors on insecure networks.

SESSION_COOKIE_HTTPONLY = True

Setting SESSION_COOKIE_HTTPONLY to True adds an extra layer of security. When this is enabled, the session cookie cannot be accessed by JavaScript code running on the client's browser. This helps mitigate certain types of cross-site scripting (XSS) attacks, where an attacker tries to steal session data using malicious scripts.

SESSION_EXPIRE_AT_BROWSER_CLOSE = True

When SESSION_EXPIRE_AT_BROWSER_CLOSE is set to True, the session will expire and be deleted once the user closes their web browser. This provides a mechanism for creating short-lived sessions that automatically end when the user finishes their browsing session. It's useful for scenarios where you want to ensure that users are logged out when they close their browser, enhancing security for shared or public computers.

Your settings.py file should contain the following:

SESSION_COOKIE_SECURE = True 
SESSION_COOKIE_HTTPONLY = True
SESSION_EXPIRE_AT_BROWSER_CLOSE = True

Authentication and Authorization

Proper authentication and authorization procedures are important for limiting access to certain parts of the web application.

In this section, I'll demonstrate how to implement user login and authentication using Django's authentication framework. I'll also define access control based on user roles to ensure that only authorized users can access certain views and features.

@user_passes_test(lambda u: u.is_superuser)
def admin(request):
    return render(request, 'admin.html', {'username': request.user.username})

The code above is used to restrict access to the admin view based on whether the user is a superuser (admin) or not.

If the user is a superuser, they are allowed to access the view, and the template admin.html is rendered with their username displayed. If the user is not a superuser, they will be redirected to a default unauthorized view, unless additional handling is implemented.

This ensures that only authorized users with admin privileges can access the 'admin.html' page.

Cross-Site Scripting (XSS) Protection

Cross-Site Scripting (XSS) is a common vulnerability that allows hackers to inject malicious scripts into web pages viewed by other users.

In this section, we'll explore how to implement Content Security Policy (CSP) headers to prevent unauthorized script execution and protect our application against XSS attacks.

CSP headers work by creating a set of rules that define which content sources are allowed and which are blocked. This significantly reduces the attack surface for XSS vulnerabilities, making it much harder for attackers to execute unauthorized scripts on your application.

It's important to carefully configure CSP policies to strike a balance between security and functionality, as overly restrictive policies could potentially break legitimate functionality in your application.

CSP_DEFAULT_SRC = ("'self'",)

Cross-Site Request Forgery (CSRF) Protection

CSRF attacks occur when malicious websites trick users into taking unauthorized actions on other sites where they are authenticated. Django offers built-in protection against CSRF attacks using CSRF tokens.

It is one of the most common methods used for preventing CSRF attacks using CSRF tokens.

When a user loads a web page that requires user interaction, the server generates a unique token and includes it in the form or the request data. This token is typically associated with the user's session. When the user submits the form or initiates an action, the server checks if the submitted token matches the one associated with the user's session. If they don't match, the request is rejected, as it might be an attempt to perform a CSRF attack.

I'll show you how to include these tokens in forms to prevent unauthorized requests.

<h4>Create Account</h4>
<form action="{% url 'create_user' %}" method="post">
   {% csrf_token %}
   <input 
      type="text" 
      id="userName" 
      name="username"
      class="form-control input-sm chat-input" 
      placeholder="username" 
    />
</form>

SQL Injection Prevention

SQL injection is a serious vulnerability that occurs when attackers manipulate user inputs to execute malicious SQL queries on the database. I'll demonstrate how Django's ORM (Object-Relational Mapping) automatically sanitizes user inputs and protects against SQL injection attacks.

It is important to note that even though Django's ORM offers robust defense against the majority of SQL injection attacks, developers must still adhere to best security practices, such as input validation and authorization checks, to guarantee the overall security of their web applications.

It's also a good idea to update Django and its dependencies frequently to take advantage of any security updates or other improvements that may be released in the future.

def search(request):
    query = request.GET.get('q')
    if query is not None:
        results = Search.objects.filter(Q(name__icontains=query) | Q(description__icontains=query))
    else:
        results = []
    return render(request, 'search.html', {'results': results})

The code above defines a Django view function that handles search functionality by extracting a query from the request's GET parameters, using that query to perform a search in the Search model using the Django ORM's filter method, and then rendering a template with the search results.

The search is performed based on the 'name' and 'description' fields of the model, and the results are case-insensitive partial matches.

By relying on Django's ORM and its built-in features, you're leveraging a higher level of abstraction that inherently helps prevent common SQL injection vulnerabilities.

This code's structure and usage patterns align with best practices for writing secure queries in Django, making it less susceptible to SQL injection attacks. But it's still important to ensure that the rest of your codebase follows security best practices and that you keep your Django version and dependencies up to date to benefit from the latest security patches.

File Upload Security

Handling file uploads requires special attention to prevent attackers from uploading malicious files. We'll see how to validate and restrict file uploads to ensure the security of our web application.

def upload_file(request):
    if request.method == 'POST':
        uploaded_file = request.FILES.get('file')
        if uploaded_file:
            if uploaded_file.content_type in ALLOWED_FILE_EXTENSIONS:
                try:
                    with open('uploads/' + uploaded_file.name, 'wb+') as destination:
                        for chunk in uploaded_file.chunks():
                            destination.write(chunk)
                    return render(request, 'success.html')
                except ValidationError as e:
                    error_message = str(e)
                    return render(request, 'fileUpload.html', {'error_message': error_message})
            else:
                error_message = "Invalid file type."
                return render(request, 'fileUpload.html', {'error_message': error_message})
        else:
            error_message = "No file selected."
            return render(request, 'fileUpload.html', {'error_message': error_message})
    else:
        return render(request, 'fileUpload.html')

The code snippet above defines a function called upload_file This function takes a request object as its argument and handles file uploads.

The function first checks if the request method is POST. If it is, then the function gets the file uploaded by the user using the request.FILES.get('file') method.

If the file is not empty, then the function checks if the file extension is in the ALLOWED_FILE_EXTENSIONS list. This list contains the file types that are allowed to be uploaded. If the file extension is not in the list, then the function displays an error message.

If the file extension is in the list, then the function tries to save the file to a directory called uploads. function uses the with open() statement to open the file in binary write mode. The file is then saved in chunks using the for chunk in file.chunks() loop.

If the file is saved successfully, then the function redirects the user to a success page. Otherwise, an error message is displayed.

The ALLOWED_FILE_EXTENSIONS list is a security measure that prevents users from uploading malicious files, such as executables or scripts. The maximum file size limit is another security measure that prevents users from uploading large files that could cause a denial-of-service attack. Storing the uploaded file in a separate directory isolates the file from the rest of the application and makes it more difficult for attackers to access it.

Wrapping-up

Building a secure web application is a continuous process that requires vigilance and implementing best practices.

In this article, I demonstrated various web security measures with code examples while building a web application using Django.

By implementing password hashing, secure session management, authentication, authorization, and protection against common web vulnerabilities like XSS and CSRF, I've taken important steps towards creating a robust and secure web application.

But web security is a vast and ever-evolving field, and it's crucial to stay updated with the latest security trends and practices to ensure your web application remains safe from potential threats. Always perform thorough security testing and regularly update your application and libraries to maintain a strong defense against potential attacks.

With the right security measures in place, you can confidently provide your users with a safe and secure web experience.

You can have access to the code here. Thanks for reading!

Encryption involves converting plain, readable data into an incomprehensible form. It's also essential to have a way to convert the data back into a readable form – otherwise the whole process makes no sense and isn't useful.

There are various popular encryption algorithms, each with its strengths and weaknesses. Understanding how these algorithms work is essential for programmers, as they need to choose the most appropriate one for their applications.

In this article, we will be build an application where users can encrypt images, and also revert the process using HTML, CSS, and JavaScript.

You will learn about working with images and how to encrypt them. The approach we will be using involves hiding one image inside another one, which is called Steganography. You will also practice some basic web development skills. It will be fun for sure!

Here's what we'll cover:

• How images are represented on your computer
• How to create the encryption algorithm
• How to create the decryption algorithm
• Photo encryption app code

How Images Are Represented on Your Computer

Understanding the way images are stored is critical before diving into encrypting them.

Images are represented on computers using a combination of pixels. A pixel is the smallest unit of an image and serves as the building block for displaying visuals on digital screens.

In memory, an image is an array of pixels. But now you're probably wondering, what is a pixel?

A pixel is assigned a specific color value which determines its appearance. The color values are typically represented using a combination of three primary colors: red, green, and blue – commonly known as RGB.

Each color channel is represented by a number value, ranging from 0 to 255, which determines the intensity of that color in the pixel.

For example:

• (0, 0, 0) represents black (absence of all colors)
• (255, 255, 255) represents white (maximum intensity of all colors)
• (255, 0, 0) represents pure red (maximum intensity of red, absence of green and blue)
• (0, 255, 0) represents pure green (maximum intensity of green, absence of red and blue)
• (0, 0, 255) represents pure blue (maximum intensity of blue, absence of red and green)

By combining different intensities of red, green, and blue, we can represent a wide range of colors. This color information for each pixel is stored in memory, forming a digital image. For example to get yellow, we can combine red and green – (255, 255, 0) represents a yellow pixel.

How to Use the Encryption Algorithm

The key idea behind the algorithm we're going to use is that it uses 2 images: the image we want to encrypt and an image that will play the role of mask used to hide the image we want to encrypt. So we're going to combine these two images in a way that hides our main image and allows its extraction.

Since an image is made of pixels, what works for a single pixel works for an entire image. We will discuss how we will be combining 2 pixels in a way that hides one and allows reverting the process.

Now for the interesting part: if we look at numbers from 0 to 255, they all can be written as follows: a 16 + b. For example 241 can be written as 15 16 + 1. But why we are doing this?

We will be using this to divide each pixel into two parts: first the a * 16 part and second b. The first part holds way more information than the second, since when a color degree goes up its intensity goes up. For example a (245, 137, 200) pixel can be split into (240, 128, 192) and (5, 9, 8).

Image splitting

Now by comparing the high value pixel and the original one, you can see clearly that using the higher value pixel instead of the original one isn't going to change much of the information the original pixel holds.

Comparing a higher value pixel and an original pixel's values

Now we will be using two pixels – one we're going to encrypt (the target pixel), and one we're going to hide the target pixel within (the encryption pixel), which can be random as we will see later.

First we will get the high value pixel from our target and encryption pixels. Then for the pixel we're trying to encrypt, we'll divide each number degree by 16.

For example if the original target pixel was (245, 137, 200) then the high value pixel will be (240, 128, 192) which will become (15, 8, 12) after applying a division by 16.

Getting initial values and applying division

Now we have two new pixels: the high value pixel of the encryption pixel, and our target pixel high value pixel that got divided by 16.

Finally, to get an encrypted pixel, we'll sum up the values of these two pixels to get what we're looking for.

Take, for example, (26, 98, 234) and (245, 137, 200) as our encryption and target pixels, respectively. Let's first get the high value pixels. We will have (16, 96, 224) and (240, 128, 192), respectively.

Now divide the target pixel high value pixel by 16 and you'll have (15, 8, 12). Now add these two up and you'll be left with (31, 104, 236). And that's our encrypted pixel.

Encrypted image

Now you know how to encrypt a pixel. By applying this to all the pixels of an image we will get an encrypted image.

To make this clearer, we will be hiding an image of Quincy Larson playing guitar within the freeCodeCamp logo 😂.

Image showing how we were able to hide Quincy Larson image in the freeCodeCamp logo

So to make this work we need two images: the one we need to encrypt and a random image to use as the encryption image. Also the two images should have the same dimensions to get the same number of pixels.

The reason we're using a random image to hide our image is to make it look like a very random image that will make no one suspicious.

How to Use the Decryption Algorithm

Now we need a way to revert the process, so to extract the target pixel from an encrypted pixel. Then we will have accomplished our goal.

Like we did earlier by combining 2 pixels to get an encrypted pixel, we will split back the encrypted pixel to get our target.

Every pixel can be split into two parts – the high value part (a * 16) and the low value part (b). Now we care about the b part since it comes from our target pixel. So we need to extract the b part from an encrypted pixel.

We can do this easily by mapping each number with its corresponding remainder of division by 16. We can do this using the modulo operator % which is a mathematical operator to get the remainder of the division of a number by another. For example 241 % 16 is 1 since since 241 is equal to 15 * 16 + 1.

By taking (31, 104, 236) and applying the modulo, we will be left with (15, 8, 12). As discussed earlier an encrypted pixel is the sum of the high value pixel of our encryption pixel or the mask pixel and the high value pixel of our target divided by 16. After the modulo is applied, the left value is the high value pixel of our target divided by 16.

Now multiply each number by 16 and you'll get exactly (240, 128, 192) which is the high value pixel of our target pixel.

Decryption

Now as you can see, Steganography involves a small loss of each target pixel's information – but it's ok as you can see that it doesn't matter much in how the final image looks.

Photo Encryption App Code

And now since our toolkit is ready, let's code this image encryption application. All the code is available in this GitHub repo. The code itself is very straightforward.

First, create three files: an HTML file, a CSS file, and a JavaScript file.

For the HTML file we just need a canvas where we can see the resulting image. We also need two inputs of type file so we can upload our target and encryption images. And finally we need a button to save our encrypted image.

Also we will be using a small library to manage images created by Duke University, so we will have to include a script tag in the end of the body for this.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Image encryption app</title>
    <link rel="stylesheet" href="index.css">
</head>
<body>
    <div class="container">
       <canvas></canvas>
    </div>
    <div class="input-container">
        <label for="Target">Upload target image</label>
        <input type="file" id="target" mltiple='false' accept='image/*'>
    </div>
    <div class="input-container">
        <label for="Encryption">Upload encryption image</label>
        <input type="file" id="encryption" multiple='false' accept='image/*'>
    </div>
    <button>Save image</button>
    <script src='https://www.dukelearntoprogram.com/course1/common/js/image/SimpleImage.js'></script>
    <script src="index.js" type="text/javascript"></script>
</body>
</html>

The CSS is simple too. We will give the div wrapping the canvas a width and height of 300px, the canvas a width and height of 100%, and it'll have a black border. Now the div tags wrapping our inputs will get a slight margin of 10px on the top, and that's it.

.container{
  width:300px;
  height: 300px;
}

canvas{
  width:100%;
  height:100%;
  border:1px solid black;
}

.input-container{
    margin-top: 10px;
}

Now for the JavaScript file. We will first select the two inputs, the canvas and the save button, and store them in four different variables. Then we will set the canvas width and height to 300px with JavaScript to avoid any future problems. And finally we'll set two variables, target and encryption, to store our encryption and target images.

const canvas = document.querySelector("canvas");
const targetInput = document.querySelector("#target");
const encryptionInput = document.querySelector("#encryption");
const saveButton = document.querySelector("button");
let target;
let encryption;

canvas.width = 300;
canvas.height = 300;

Now we need to store the encryption and target images on user upload in the two variables we created earlier. Also set the onClick event of our save button to a function called save that we will create next. Finally, we'll create a function that takes a number as an argument and returns its high value as discussed in the encryption algorithm section.

targetInput.onchange = (e) => {
  const img = new SimpleImage(targetInput);
  img.setSize(300, 300);
  target = img;
};

encryptionInput.onchange = (e) => {
  const img = new SimpleImage(encryptionInput);
  img.setSize(300, 300);
  encryption = img;
};

saveButton.onclick = save;

function getValue(x) {
  return x - (x % 16);
}

All that's left is to create the save function. First we will create a new image object with dimensions of 300 * 300. An image with these dimensions will have 90000 pixels. All of them have x and y coordinates from 0-299, since indexing starts from 0 in arrays. Looping from 0 to 300 twice will allow us to get all possible coordinates which means all pixels.

Now for each coordinate we will use the corresponding pixel of our encryption, target, and newly created image. Now we can set each pixel of our newly created image to the sum of the high value pixel of the encryption pixel and the high value pixel of our target divided by 16.

Now we will draw the newly created pixel on the canvas. And we'll need to get the URL of the image drawn into the canvas. We will be applying a small modification to the URL otherwise it will not work because we will get blocked by the browser for security reasons.

Finally, navigate to this URL by setting the window location to that URL. Then the encrypted image will be downloaded.

function save() {
  const img = new SimpleImage(300, 300);
  for (let i = 0; i < 300; i++) {
    for (let j = 0; j < 300; j++) {
      const targetPixel = target.getPixel(i, j);
      const encryptionPixel = encryption.getPixel(i, j);
      const pixel = img.getPixel(i, j);
      pixel.setRed(
        getValue(targetPixel.getRed()) / 16 + getValue(encryptionPixel.getRed())
      );
      pixel.setGreen(
        getValue(targetPixel.getGreen()) / 16 +
          getValue(encryptionPixel.getGreen())
      );
      pixel.setBlue(
        getValue(targetPixel.getBlue()) / 16 +
          getValue(encryptionPixel.getBlue())
      );
    }
  }
  img.drawTo(canvas);
  let url = canvas
    .toDataURL("image/png")
    .replace("image/png", "image/octet-stream");
  window.location.href = url;
}

And that's it for the code 😇.

Conclusion

In this article, we've learned a simple algorithm for image encryption. Modern algorithms are way more robust, as they use techniques like matrix multiplication to get solid hashing algorithms but they are very complex and require way more time and math knowledge than this one.

If you find this content enjoyable, follow me on LinkedIn as I post great content there 😉.

In this article, we will explore the famous (or infamous) sphere of social media, why it is critical to both you and hackers, and how you can avoid having your social media accounts attacked.

Disclaimer: Hacking is a tool with the potential for both good and bad. Under no circumstances should the knowledge in this article be used for any harmful or illegal purposes. Doing so could lead to a long time in a jail cell 💀.

And with that, let’s jump in 🙃.

What We’ll Cover

1. Overview of Social Media Platforms

2. Attack Techniques

3. Defense Tips

Overview of Social Media Platforms

Media is Everything ¦ Credit: Anledry Cobos

Meta (formerly Facebook) remains one of the biggest companies on the planet.

Starting off in 2004, it redefined the way we interact with, share, and engage with the world around us. With roughly 2.98 billion monthly active users, Facebook has become an integral part of modern society, bridging gaps and fostering virtual communities.

The platform was among the pioneers of the social media craze which introduced the world to more apps such Instagram, Snapchat, Reddit, WhatsApp, YouTube, TikTok, Telegram and most notoriously, Twitter 🐦. Each and every single one of these apps have a different feel and taste to them with one underlying purpose: Connections.

Connections to people, places and products have been the centre of it all. These platforms allow you to interact with friends, as well as strangers. They also help you see the world around you in ways no one thought was possible many years ago. And if you’re a business person or content creator like I am, it allows you to show people what you have to offer.

If an attacker compromises your credentials, they have access to your connections. They could use your data to impersonate you, post illegal and harmful things, damage your reputation, spread malware, and social engineer your friends and followers on the platform in order to steal money and compromise their accounts.

According to Gitnux, there are about 1.4 billion attacks on social media platforms monthly – quite a lot isn’t it?

Giga Chad ¦ Credit: The Hacker Community

Many companies take the cybersecurity of their infrastructure quite seriously (most times anyway 😶). But as a consumer, you are your own last line of defense or your own greatest vulnerability.

In this article, we will take a look at some ways attackers can convert your ‘connections’ into profit and how you can defend against them. Now let’s find out how hackers can compromise your account.

Social Media Account Attack Techniques

A ‘Like’ signboard on 1 Hacker Way ¦ Credit: [Greg Bulla](https://unsplash.com/@gregbulla?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener noreferrer)

Physical Access

This may seem obvious, but people still make this mistake a lot. An attacker could install scripts or software that would let them get the passwords of your social media accounts if they have your phone or laptop in their hand.

Software like those from Passrevelator make it easy to get passwords and other credentials from devices on different platforms.

Phishing links, emails, and sites

Phishing is a cyberattack in which the attacker tricks the victim into giving sensitive or critical information through fraudulent websites, forms, links or other means.

It’s pretty easy for anyone to make a Facebook clone with React Native. Tools like Zphisher and PyPhisher make it even easier for an attacker by setting up a phishing page and creating links to it, too.

As you can see, PyPhisher comes with a wide array of options for some major mayhem.

The Phyphisher Interface ¦ Credit: Mercury

More seasoned criminals can send links in spoofed emails to make them look like they are from official organisations and can register lookalike domains to trick users.

Password Spraying and Bruteforcing

Passwords are a big security concern, and for good reason. They are often repetitive and easy to guess. Spraying is the process of trying out common passwords while Bruteforcing is the process of trying out all possible combinations to gain access.

Attackers can get the passwords they use in password spraying from common wordlists. Wordlists are a list of passwords usually gotten from data breaches. The larger the wordlist, the higher the chances of compromising any account.

Below is a screenshot of the infamous rockyou.txt wordlist from the RockYou hack of 2009.

The rockyou.txt wordlist ¦ Credit Mercury

Bruteforcing, on the other hand, involves the attacker generating a custom wordlist alongside usernames or emails on different platforms. This is more effective if the attacker has a specified target.

As you can see, attackers can use a tool known as crunch to generate a wordlist, and it has a lot of options.

Crunch in action ¦ Mercury

If an attacker uses these techniques on a login page, this has great potential to be an entry point, especially if the site has poor security.

Keyloggers

A Keylogger is a piece of riskware that keeps track of what a person types on their device. Think of it like your keyboard having a memory card and sending what it stores to an attacker.

Note that keyloggers aren’t inherently bad, as they can also be used for organisational monitoring and parental control. But an attacker does not have authorization to monitor your keystrokes, which makes its use illegitimate.

An attacker could install a keylogger and monitor the victim's keystrokes. All they have to do is wait and read the logs for a peculiar sequence, usually one with an email, followed by a string of characters before the ‘return’ keystroke.

It would usually look something like this:

A slightly modified Keylogger log ¦ Credit: Mercury

Usually, the entire log will be monochrome but for this example I made a few modifications. The red highlight indicates an email account, which is what an attacker would be looking for. Close behind is the password in blue.

Network Sniffing

Also known as packet sniffing, this is the practice of intercepting and analysing network packets in order to find out what kind of information is shared within the network.

If connections are not properly encrypted, an attacker could easily obtain sensitive information about the sites visited and the messages and passwords that are sent and inputted in them, respectively. WireShark is one of the most common tools for this kind of attack.

The Wireshark Interface ¦ Credit: Mercury

Data Breaches

Data breaches are unintentional leaks of sensitive or confidential information. These are usually more devastating to users than organisations and could have far-reaching consequences.

Passwords and login credentials from data leaks can be sold and purchased on the dark web. They are then used to gain unauthorised access to the account and the rest is history.

How to Defend Against Social Media Attacks

A Neon Instagram Heart ¦ Credit: [Prateek Katyal](https://www.pexels.com/@prateekkatyal/" rel="noopener noreferrer)

As you can see, there are many ways to obtain Social Media account credentials. Below are some ways to ensure you are not a victim.

Check the URL

Always double check any links sent to you via messaging platforms or email. This is a simple but very effective measure against phishing links and sites, as the likelihood of clicking on the wrong link is much lower.

For example, www.facebook.com and www.facebok.com are not the same. As you can observe in the screenshots below, the former is legitimate while an antivirus warns me that the later is a phishing site.

facebook.com ¦ Credit: Mercury

facebok.com ¦ Credit: Mercury

Use strong passwords/passphrases

Make sure you use strong passwords and don’t use similar passwords for different accounts (not even variants 👀). You can also use passphrases rather than passwords as they are easier to remember but harder to guess or bruteforce.

An example of a password is 'dictionary'. An example of a passphrase is 'mydictionaryisthelargest'. The password is weak and could be guessed or found easily in a wordlist. The passphrase isn't the strongest but it is quite lengthy and would be almost impossible to find in a wordlist or to be guessed.

Use Antivirus Software and Firewalls

An Antivirus is a software solution that protects systems against both internal and external threats based on the vendor. A Firewall, on the other hand, protects systems against external threats based on your preferences and settings.

The use of one or both of these products can go a long way in protecting both individuals and organisations from information stealing malware.

VPNs

A Virtual Private Network is a secure network connection that connects you to the internet privately and anonymously. This is done by encrypting the connection and routing it through remote servers.

VPNs are a great option to avoid packet sniffers because packets analysed are encrypted. This means it’s going to be quite difficult for an attacker to get passwords from technical gibberish.

Tracking Breaches

Tracking breaches can be done at an individual or enterprise level. It’s effectiveness, however, usually depends on how much you are willing to pay for it.

Individuals can use sites like haveibeenpwned.com to check if their data has been compromised in any breaches and Enterprises can setup security units with the role of constantly monitoring the Internet for breaches related to them.

Conclusion

Social Media in Scrabble ¦ Credit: [Visual Tag Mx](https://www.pexels.com/@visual-tag-mx-1321732/" rel="noopener noreferrer)

Getting credentials is pretty easy with some determination and a touch of mischievousness. But companies have gotten better at defense in recent years and attackers have had to get more creative.

As an individual, you are your last and dare I say best line of defense. Ensure your shields are always up in the online jungle. Stay safe and Happy Hacking 🙃.

Acknowledgements

Thanks to Anuoluwapo Victor, Chinaza Nwukwa, Holumidey Mercy, Favour Ojo, Georgina Awani, and my family for the inspiration, support and knowledge used to put this together. You’re the best.

Resources

1. Social Media Attack Statistics

2. GUI tools for physical access hacking

Before you can really improve the security of your Amazon EC2 instances, you'll need to get a handle on all the stuff that can go wrong. And I'll give you a bit of a "hall of shame" rundown in just a minute.

What's the Problem?

But first, by way of introduction, I want to tell you a really scary story. So scary, that you should perhaps prepare by turning on all the lights in your room and grabbing a soft blanket for comfort.

Here goes. Based on my own past experiences, I just conducted a brief experiment. I launched an EC2 instance running Ubuntu into one of my AWS accounts. The instance wasn't running anything more than whatever Ubuntu gave me by default and it wasn't associated with any DNS addresses.

Its only connection with the outside world was through the public IP address AWS assigned it. In fact, the only difference between this instance and one that you or I might normally run is that I opened up its security group to permit all incoming traffic.

Since Ubuntu, by default, doesn't run an active firewall, there would therefore be nothing standing between the instance and the big bad internet.

This article comes from my Securing Your AWS EC2 Instances course. If you'd like, you can follow the video version of this section here:

So what happened? Well, the auth.log entries on the host were astounding. According to those logs, the system came up for the first time at around 14:56. Here's a little of what I saw just 35 minutes later:

Someone was trying to log in to my system via SSH using the user name root. Now, of course, by default, root login is disabled - and you should leave it that way. But that didn't stop this individual from trying.

Note how they didn't just use the standard SSH port 22, but played around with alternative port numbers (including 51912 as well). That suggests that this attempt was part of an automated script that tests various combinations of usernames, passwords, and ports:

Aug 10 15:31:17 ip-172-30-1-186 sshd[2777]: error: maximum authentication attempts exceeded for root from 20.210.53.189 port 51912 ssh2 [preauth]

But they weren't done. Over the next 75 seconds, 30 more login attempts came from this same IP address. They pointed to different ports in the 50,000 range, and used different usernames like, admin, oracle, test, test1, test2, ftpuser, and pi.

The fact that they tried pi tells me that they didn't realize that this was a cloud instance but that, for all they knew, it could have been a Raspberry Pi running in someone's home lab.

I don't know about you, but I find this really frightening. Sure, which admin would purposely open up a security group to all incoming traffic? But the real point is that there are so many scripts out there constantly scanning for live IP addresses and then trying to brute force system logins, that any random IP address can expect hits within minutes.

And, again, this isn't the first time I've seen this in action, nor is SSH the only public-facing service that attracts such attacks. At the very least, we should take this as a warning to tighten up our SSH configurations - which is something I will discuss later.

But here's the thing. It is possible to achieve perfect security - it really is - but that would involve completely locking your servers down and blocking all access from the outside world. What's the point of running servers like that? The goal is to find the best possible balance between application functionality and infrastructure security.

Establishing that balance might include incorporating all the general IT security basics like system hardening and monitoring, alongside the intelligent use of key AWS security features like IAM roles, security groups, appropriate VPC architectures and, where appropriate, the use of VPNs.

So just what's out there waiting to dig its claws into your AWS operations? Well there are hackers' tools for getting into your system, exploits for taking over and misusing your resources, and methodologies for bringing down your services by force. Let's look at these one at a time.

Access Acquisition

As you might have noticed from the maximum authentication attempts exceeded content of those log entries I showed you earlier, the hacker tried entering multiple passwords for each login name.

That's known as a brute force attack, where hackers rotate through a dictionary of common passwords, hoping that one will turn out to be correct.

The reason my system cut those attempts off completely is because the official EC2 Linux images have a default SSH configuration setting - MaxAuthTries - set to six. Even if you did permit password logins for SSH - and even if you did irresponsibly use a weak password - the odds against a hacker getting it right within six tries are pretty slim.

If you'd like, you can follow the video version of the second part of the article here:

Of course, if a hacker can get hold of real, active credentials, then they won't need to guess. That's why you should be aware of phishing attacks where hackers use social manipulation to get victims to unknowingly reveal their login information.

They can similarly take advantage of communications that take place using compromised devices or that are sent over unencrypted connections to sniff your credentials as you use them.

In cloud terms, just imagine how much fun someone could have once they get hold of your AWS account credentials. That would allow them to quickly run up hundreds of thousands of dollars worth of bills on your credit card, by deploying nearly endless AWS resources in service of their own criminal needs. Besides having to cover those bills, you might also get blamed for any crimes committed with those resources.

Exploits

Once hackers have gained access to your system, things can only get worse. Whether they do something nasty right away or hang around for months planning something particularly nefarious, if you don't catch them at it, eventually they'll install their malware.

That might take the shape of keyboard trackers that record every character you and your colleagues enter in a shell session. It'll only be a matter of time before those trackers capture credentials that'll let them elevate their own permissions.

The malware could also take the form of cryptocurrency mining operations that make heavy - and expensive - use of your system resources so the hackers can profit. Or - and this is the most frightening - they might decide to encrypt key data on your drives and demand large payments before they'll let you decrypt and regain access.

This, of course, is known as ransomware, and it's currently the biggest problem facing enterprise-level systems. It costs governments and companies billions of dollars each year.

Service Disruption

Even if they don't get into your system, the bad guys can still do a lot of damage from the outside. If, for instance, they detect misconfigurations on your servers - like unnecessarily open network listening ports, poorly written database endpoints, or outdated software like FTP or telnet, they can cause you plenty of problems.

And, for those criminals with access to networks of hijacked zombie servers, they could overrun your network capacity with distributed denial of service attacks - preventing your legitimate users from accessing your services.

Fortunately, AWS provides some serious protection from DDoS out of the box, so that's not likely to be a big concern for you as an admin.

Speaking of AWS engineering, now's probably a good time to discuss their Shared Responsibility Model. The way the company phrases it, AWS is responsible for the security of the cloud while their customers - that would be you and me - are responsible for the security of whatever you put in the cloud.

Practically, that means you don't need to worry about terrible things happening to the physical servers and storage devices used by your EC2 instances. AWS will protect their warehouses and networking hardware from unauthenticated intrusion and harm. They'll also take responsibility for the software powering any of their managed services - like the API and dashboards you use to configure account activity.

But you're responsible for everything else. That includes the data your instances might generate and the operating systems themselves. So you're on the hook for keeping your operating system and application software patched, and for making appropriate backups of all the data and configuration files you generate.

You're also responsible for making the right AWS-level configuration choices, like getting your security group and network settings right. Depending on the industry and national jurisdiction within which you operate, you might also be expected to meet one or more regulatory compliance standards.

AWS provides documentation laying out which standards each service meets. If you open the web page shown below, you could expand the Payment Card Industry - PCI - section, for instance, and then search for EC2. You'll see that EC2 infrastructure is, indeed, PCI-compliant;

We've seen how vulnerable your EC2 instances are when they're left without adequate protection. But we've also seen some industry best-practices for keeping them secure. You know what your next step is.

This article comes from my Securing Your AWS EC2 Instances course. And there's much more technology goodness available at bootstrap-it.com

Smartphones have become an essential part of our daily lives with instant access to information at the touch of a button. Whether we’re checking our social media feeds or responding to work emails, they are always within arm’s reach. It's no wonder that these devices offer a wide range of functions, from GPS navigation to streaming music.

In 2023, the number of smartphone users worldwide is projected to reach 6.8 billion, a growth rate of 4.2% per year.

As we all depend more and more on our smartphones, the importance of securing them is at an all-time high. Cybercriminals can target your device using malicious apps, phishing, and even more sophisticated attacks.

As almost every aspect of our lives is now connected to our smartphones, a hacker gaining access to your device can be a nightmare scenario. Being the victim of a smartphone hack can be a distressing experience that can leave you feeling exposed and violated.

They can steal your personal information, bank account details, or social media passwords. The repercussions can be severe, ranging from financial loss to reputational damage.

I have outlined the 7 most common ways hackers can reach your smartphone. We will also see tips on how to protect your device from cyberattacks.

Keep reading to learn how you can keep your smartphone and data safe from those who try to exploit it.

Smishing Attacks

Smishing is a type of phishing attack that hackers use to get access to sensitive information through text messages. An attacker will send you a link to click through a text message making it appear from a legitimate source.

Due to the limited display of URLs in mobile browsers, Smishing can be difficult to detect on mobile devices. This makes Smishing as effective as email phishing.

Knowing the source of text messages is crucial. This applies to messaging platforms like WhatsApp as well. Always be wary of clicking links or responding to messages from unknown numbers.

According to the FBI’s 2020 Internet Crime Report, Smishing accounted for nearly a half-billion dollars in losses in 2019.

Breaking in via Bluetooth

Bluetooth is another easy way with which hackers target smartphones. Smartphones are vulnerable to Bluetooth hacking due to weak security protocols.

Hackers can gain access to calls, texts, and authentication codes via Bluetooth. It becomes easier for hackers to break into your device if you leave your Bluetooth connection unregulated. Luckily, physical proximity to the device is important for Bluetooth hacking.

Attackers can exploit weak wireless connections in public spaces. The automatic pairing of devices with visible Bluetooth signals makes it easy for attackers to exploit. To ensure safety, you must turn off your Bluetooth unless necessary and disable auto-pairing.

Malware Attacks

Malware is any software designed to harm computers, networks, or mobile devices. It can come in various forms such as viruses, spyware, adware, or Trojans.

Hackers can use malware to steal your account credentials, check your online activity, or even take control of your device. To avoid malware, ensure that your device’s software is up-to-date.

Install apps only from the app store or play store and never install them directly from third-party websites. Consider using antivirus or anti-malware software to protect your smartphone.

In the first half of 2020, more than 3.2 billion malware attacks have been registered by SonicWall.

Malvertising

Malvertising is another popular tactic used by hackers to target smartphones. It involves using malicious advertisements to spread malware or spyware on various devices.

Malvertising works by delivering malicious ads via online advertising networks. These malvertisements are often found in illegal or pornographic websites.

Installation of malware or spyware on your device leads to instant compromise of your device. To protect your smartphone, avoid clicking on unknown ads or visiting suspicious websites.

The annual malvertising revenue on pirating websites is projected to be $1.34 billion.

Social engineering

Social engineering is another popular attack vector used by hackers to access confidential data. It involves tricking users into providing sensitive information. This information could be your email, password, or even credit card information.

To protect your device from social engineering attacks, you should be wary of suspicious emails, messages, and phone calls. If a message or call requests personal information, double-check and make sure it is a legitimate source.

Social engineering attacks are also common in the workplace. If someone from your company is requesting suspicious information, check and make sure the request is from them via alternate communication channels.

23% of social engineering breaches resulted in the confirmed disclosure of data to an unauthorized party.

Pretexting

Pretexting is another technique used by hackers to gain access to confidential data. It involves creating a false pretext or story to convince an individual to reveal sensitive information.

Cybercriminals use pretexting attacks to steal passwords, credit card numbers, and personal details.

Never give out any personal information unless you are certain of the recipient’s identity. If you receive any suspicious messages via email or text messages, ignore them or report them to your organization’s security team.

Phishing and pretexting accounted for nearly all of the social breaches with 93% of the incidents. Email was the most utilized attack vector (96%).

Man-in-the-middle Wi-Fi Attacks

One of the most common ways hackers can target your smartphone is through man-in-the-middle Wi-Fi attacks. These attacks happen when you connect to public Wi-Fi or an unsecured network.

The hacker intercepts communication using tools like Wireshark and obtains information. Hackers can also access and manipulate data through hacked routers, which can lead to devastating consequences.

It’s important to note that these types of attacks do not need the hacker to take control of the user’s device, which makes them particularly dangerous. Wireless networks are vulnerable to a variety of attacks, so always be cautious when connecting to public Wi-Fi networks. Additionally, use a VPN to mask your network traffic.

In 2019, 35% of attacks were attempts at exploitation through MITM attacks.

How to Protect Yourself from Smartphone Attacks

Now that we have seen 7 ways hackers can target your smartphone, let me summarize the key points to protect yourself.

1. Download apps from trusted sources & install mobile antivirus software:

Always download apps from legitimate stores like the Apple app store or Google Play Store. Never download third-party apps or .apk files to your device. Ensure to use mobile antivirus software to protect your device from malware attacks.

2. Beware of phishing emails & use strong passwords:

Be wary of any emails that ask you to click on a link or enter personal information. Always use unique, complex passwords for your online accounts. Also, try to use two-factor authentication when possible.

3. Stay up-to-date with security patches:

Ensure to update your operating system and apps with the latest security patches on a regular basis. Most software updates include security patches, and these vulnerabilities will be publicly disclosed. So, if you don’t update your device, you become an easy target for attackers.

4. Use a VPN (Virtual Private Network):

When connected to public Wi-Fi networks or other unsecured networks, use a VPN to protect your data from hackers. This prevents unwanted snooping by malicious actors by using tools like Wireshark.

5. Disable Bluetooth & GPS services when not in use:

Ensure that your Bluetooth and GPS services are not active when they are not required. This will further reduce attack vectors for malicious actors.

Summary

Smartphone hacking is an unfortunate reality. It can leave users vulnerable to identity theft and financial loss.

To keep your smartphone device secure, do not give out personal information to untrusted sources. Stay vigilant and use the above-recommended security practices to ensure the safety of your smartphone.

If you found this article useful, join the Stealth Security newsletter to get an email every Friday. We will include our articles, videos and the latest news from the world of Cybersecurity.

Encryption is an integral part of our daily lives – whether you are sending messages to friends on WhatsApp, visiting a website and your browser is making sure it's legitimate, or entering your bank details when buying something online. Encryption protects your data from potentially malicious and prying eyes.

This article will cover:

• Encryption algorithms and keys

• Symmetric and asymmetric key encryption

• How TLS/SSL uses both symmetric and asymmetric encryption

Encryption Algorithms and Keys

At the start of this article, I described encryption as a way of scrambling data so that it can only be read by the intended recipient. Let’s break down what this means.

Let's say you want to write a letter to your friend and want to ensure that only the friend can read its contents. How would you prevent the prying eyes of all the intermediaries the letter could pass through before it gets to your friend? That is, how do you prevent the postman, the concierge in their building, or one of their friends from reading the letter?

You start with an unscrambled letter that anyone can read. This is called plaintext. To scramble the contents of the message, you need an encryption algorithm and a key. The encryption algorithm uses the key to scramble the contents of the message. This encrypted message is called ciphertext.

The process of encryption is shown in the image below:

When your friend gets the message, they will need to descramble it using the algorithm and the key. This is illustrated below:

The two key ingredients needed to send a message to your friend that only they can read is an encryption algorithm and a key.

The encryption algorithm is simply a mathematical formula designed to scramble data, while the key is used as part of the formula. The encryption algorithm is generic, but the key, used as an input to the algorithm, is what ensures the uniqueness of the scrambled data.

Let’s look at one of the simplest encryption algorithms, called the Caesar Cipher. In its simplest form, this algorithm simply replaces each letter by the next letter in the alphabet. So A becomes B, and B becomes C and so on.

With this algorithm, the text ‘Birthday Surprise’ becomes ‘Cjsuiebz Tvsqsjtf’, indistinguishable from gibberish to the untrained eye.

With the Caesar Cipher example, the algorithm is the formula used to replace each letter of the alphabet with another. The key is the number of shifts made between each letter. With a key of 0, A is A, an obviously poor choice of key as the data is unscrambled. With a key of 1, A becomes B. With a key of 10, A becomes K.

The Caesar Cipher is a relatively poor encryption algorithm. Why? Since there are only 26 letters in the English language, you can only produce a maximum of 25 possible ciphertexts. If you don’t have the key, you only need to shift each letter up to 25 times until you see coherent words and sentences, at which point you know that you have successfully decrypted the message.

A bad encryption algorithm is one that is easily decrypted by using a small amount of brute force (that is, trying every possible permutation) – and 25 possible ciphertexts is an objectively small number of possible options to go through.

Modern encryption algorithms like AES-256 used by AWS, GCP, and Azure for encrypting data are considerably more complicated and secure than the Caesar Cipher. Based on current computing capability, it would take trillions and trillions of years for the most advanced supercomputer to use brute force to decrypt data encrypted using AES-256 [1]. Even the universe is not that old.

Symmetric and Asymmetric Key Encryption

The core of any encryption process is the encryption algorithm and the key. There are many types of encryption algorithms. But there are, broadly speaking, two types of keys – symmetric and asymmetric keys.

In symmetric key encryption, the same key used to encrypt the data is used to decrypt the data. In asymmetric key encryption, one key is used to only encrypt the data (the public key) and another key is used to decrypt (the private key).

Asymmetric key encryption

First, let’s look at asymmetric key encryption with a simple analogy.

Imagine you wanted to send something to your friend, but it was absolutely essential that nobody else, except your friend, could have access to that object. So, your friend buys an indestructible box, fabricated from the strongest metal on the planet, and sends it to you so that you can place the object in it. Your friend also sends you the key that can only be used to lock the box.

Now, this box has one more special property. It has two keyholes. One keyhole to open the box, another to lock the box.

Naturally, this box will also need two keys – one to open and another to lock it.

Both keys are similar, but not identical. As you can see in the image above, for example, the key used to open the box has two prongs while the key used to lock the box has three prongs.

As the sender of the object, all you have is the box to place the object in and a key to lock the box. Only your friend has the key that can unlock the box.

The key used to lock the box is called the public key, and cannot be used to open it, as that requires the private key. If anyone intercepted the package and made a copy of the public key, it could not be used to open the box, only to lock it. Only the person who holds the private key can open the box.

Asymmetric key encryption is used when there are two or more parties involved in the transfer of data. This type of encryption is used for encrypting data in transit, that is encrypting data being sent between two or more systems. The most popular example of asymmetric key encryption is RSA.

Symmetric key encryption

Symmetric key encryption uses the same key for encryption and decryption. This makes sharing the key difficult, as anyone who intercepts the message and sees the key can then decrypt your data.

This is why symmetric key encryption is generally used for encrypting data at rest. AES-256 is the most popular symmetric key encryption algorithm. It is used by AWS for encrypting data stored in hard disks (EBS volumes) and S3 buckets. GCP and Azure also use it for encrypting data at rest.

How TLS/SSL Uses Both Symmetric and Asymmetric Encryption

The main strength of symmetric key encryption is that it is computationally easier and faster to encrypt and decrypt data using a single key, just as it is easier to build a box with a single lock and key.

The weakness of symmetric key encryption is that if the key is exposed, your data is no longer securely encrypted. So, if you needed to share the key with an external party, there is a risk that the key could be exposed, leaving your data at risk of being decrypted.

Symmetric key encryption is ideal for encrypting data at rest, where you do not need to share the key with another system.

With asymmetric encryption, this is not a problem since two separate keys are used – the public key to encrypt data and the private key to decrypt data.

The public key can be easily shared with anyone and poses no risk to your data being decrypted, since the private key is needed for decryption.

The drawback of asymmetric key encryption is that the encryption and decryption process is slower and more complicated. Asymmetric key encryption is ideal for encrypting data in transit, where you need to share the key with another system.

What if there was a way of getting the speed and computational simplicity of symmetric encryption without increasing the risk of exposing your keys?

TLS/SSL encryption use both symmetric and asymmetric keys to encrypt data in transit, and is used with the HTTP protocol for secure communications over a computer network.

TLS/SSL Encryption Explained

TSL (Transport Layer Security) and SSL (Secure Sockets Layer) are often used interchangeably to mean the same thing. But when people say SSL, they often mean TLS.

TLS is generally considered more secure than SSL due to several improvements made to the protocol, such as stronger cryptographic algorithms. Due to security concerns with SSL, most modern web browsers and applications have dropped support for SSL and only support TLS. As a result, TLS has become the standard for secure communication over the internet.

How to Use Symmetric and Asymmetric Encryption at the Same Time

Let's say you want to securely send a parcel to your friend. But you don’t want to keep using the special indestructible box that has two keyholes and two locks. It is expensive, heavy and impractical to use for frequent communications. You still want to use an indestructible box, but one that is simpler, with a single lock and key.

However, if you are using a box with only a single lock and key, you now need to figure out how to securely share the key for that simpler box with your friend.

Since the same key is used to both open and lock it, you cant just send the key to your friend without somehow protecting it first. If the key is intercepted and a copy is taken by someone, they can now open your box and take what is inside.

How can you securely share this key with your friend so that you can use this simpler box for future communication?

1. First, your friend sends the box with the two locks plus the public key used to lock it. But you don’t want to keep using this box. You will only use this box once – to transfer the key for another simpler box that you will use for future exchanges.

2. You place the master key that will be used in future exchanges inside this box and lock it with the public key sent by your friend.

3. You send the locked box which contains a copy of the master key inside back to your friend.

4. Your friend uses his private key to open the box. Now you both have the master key and can be sure no one else has it since it was sent in a secure box

5. All future items are then placed in this simpler box with a single lock and key which can be opened and locked using the master key you just sent to your friend.

TLS/SSL Encryption Sequence

The analogy in the previous section neatly maps to how TLS/SSL encryption actually works. But there are some prerequisite steps which I ignored in this analogy, like creating a TCP connection and the server sending its certificate (Steps 1 and 2 below).

Also, Step 6 is a simplification of the process. In reality, the master key is used to generate a further set of keys that the client and server will use to encrypt and decrypt messages and also to authenticate that the messages were indeed sent by the client and server.

To read more about the low level detail, I’d recommend Chapter 8 of "Computer Networking" by Kurose & Ross.

But, at a high level, the sequence is as follows:

1. Client establishes TCP connection with the server

2. Client verifies that the server is who it says it is – server sends certificate which has the public key. The accompanying private key remains with the server.

3. Client creates a master secret key and uses the server's public key to encrypt it. This master secret key is a symmetric key so the same key is used for encryption and decryption.

4. Client sends the encrypted master secret key to the server.

5. Server decrypts the encrypted master key using its private key.

6. All future messages between client and server now use the symmetric master key to encrypt and decrypt messages.

Best of Both Worlds

Using both symmetric and asymmetric key encryption gives you the speed of symmetric key encryption without compromising on the extra security provided by asymmetric key encryption.

But nothing comes for free, of course. With TLS, there is an added layer of complexity since you need to first use asymmetric keys to establish a secure connection before exchanging the symmetric key for future communication.

So by using both symmetric and asymmetric encryption, TLS/SSL gets the best of both worlds with limited downsides.

With the crawling capabilities of Google, it can also be a powerful tool for pen testers. Google can help us find exposed files, scripts and other critical resources in web applications.

To find this type of sensitive information, hackers use specific search terms in Google. We call them Google Dorks.

Google Dorks are special search terms that help locate information which is not found through regular web searches.

In this article, we will look at what Google Dorks are and how they can help us in penetration testing.

What are Google Dorks?

A Google Dork is a special search term. These terms, when used with regular search keywords, can help us discover hidden resources crawled by Google.

These resources include sensitive information such as usernames, passwords, credit card numbers, email addresses, shell scripts, user accounts, and so on.

These Dorks are not limited to Google. We can also use them with search engines like Bing and Yahoo. The results might vary, but they still serve the same purpose.

To harness the full potential of Google Dorking, we’ll need to master some specialized search operators. These operators will fine-tune our search results and help us find exactly what we are looking for.

Let’s try a few Google dorks.

Common Google Dorks

Some of the common query operators in Google Dorking include search modifiers. These search modifiers allow us to find specific information that may not be accessible through traditional search methods.

Here are some of the most common operators used in Google Dorking.

Intitle operator

The “intitle” operator searches for web pages with specific words or phrases in the title tag. For instance, if you’re looking for pages that contain the phrase “password” and have “index of” in the title, you would use the search term:intitle:”index of” password.

In title. Image by the author.

Inurl operator

The “inurl” operator searches for web pages that contain specific words or phrases in the URL. For example, if you’re looking for pages that contain “admin.php” in the URL, you would use the search term:inurl:admin.php.

In url. Image by the author.

Site operator

The “site” operator allows you to search within a specific website or domain. For instance, if you’re looking for pages on the example.com domain that contain the word “Steganography”, you would use the search term:site:yeahhub.com “Steganography”

In site. Image by the author.

Filetype operator

The “filetype” operator allows you to search for specific file types, such as PDFs or Word documents. For example, if you’re looking for PDF files that contain the phrase “confidential report”, you would use the search term:filetype:pdf "Advanced Network Security"

Filetype. Image by the author.

Intext operator

The “intext” operator searches for pages that contain specific words or phrases within the body of the page. For instance, if you’re looking for pages that contain both the words “login” and “password” within the body of the page, you would use the search term:intext:"about" contact.

In text. Image by the author.

Link operator

The “link” operator searches for web pages that link to a specific URL. For example, if you’re looking for web pages that link to the example.com domain, you would use the search term:link:”example.com”

Link operator. Image by the author.

Cache operator

The “cache” operator is used to retrieve the cached version of a web page. When you search for a website using Google, Google creates a cached version of that page in its system. This version can be useful if the original website is temporarily down or if you want to view an older version of the website.

Here is the syntax to find the cached version of yahoo.com.cache:https://www.yahoo.com

Cached version of yahoo.com. Image by author.

Related operator

The “related” operator is used to find web pages that are related to a specific URL. Here is the syntax to use the “related” operator to find sites similar to yahoo.com.

Related operator. Image by author.

By combining these operators in creative ways, you can find specific types of information on the web that can be useful for penetration testing and other purposes.

Structure of Query Operators

Google Dorking query operators have a structure similar to regular Google search query operators. This technique involves using advanced operators and search queries to uncover information that is not typically available through regular searches.

The general structure of query operators in Google Dorking includes three elements:

1. Operator: A specific keyword or symbol that instructs Google what to search for. For instance, the “inurl” operator searches for pages that contain a particular keyword in their URL.
2. Keyword: The search term or phrase that you want to find. If you are looking for a specific password file, then “password” is your keyword.
3. Modifier: An additional search parameter that you can use to further refine your search. For example, the “filetype” modifier searches for a specific file type, such as a PDF.

Here’s an example of a query operator structure in Google Dorking: intitle: “index of” site:example.com password filetype:pdf

This query uses the “intitle” operator to search for pages with “index of” in their title, the “site” operator to search within the example.com domain, the keyword “password,” and the “filetype” modifier to search for PDF files.

By utilizing query operators in Google Dorking, we can find useful and often vulnerable information that might not be accessible through regular searches.

Google Hacking Database (GHDB)

The Google Hacking Database (GHDB) is a compilation of search queries and query operators that help us in Google Dorking.

Google hacking database. Image generated by author.

Johnny Long, a well-known security researcher and author, established the GHDB. It has since become a valuable resource for security engineers like you and me.

The GHDB has several search queries and operators that can uncover numerous sensitive files, vulnerable web servers, and applications. It can also discover default login pages and credentials, as well as network and security devices that may be prone to attack.

GHDB is arranged into categories such as “Files containing passwords” “Vulnerable servers” “Footholds” and “Error Messages”. Each category contains several search queries and operators crafted to reveal specific information about a target.

Please note that search queries and operators in the GHDB might produce false positives or outdated information. Always verify the information obtained through these search operators.

A Dorking Scenario

Let’s assume you have to conduct a pentesting audit for a client. Here is a sample dorking scenario.

1. Use the “site” operator to limit your search to the company’s website: site:example.com. This returns all pages on the example.com website.
2. Use the “intitle” operator to search for pages containing specific keywords in the title: intitle:”login” site:example.com. This helps identify potential login pages vulnerable to attack.
3. Use the “filetype” operator to search for specific file types: filetype:pdf site:example.com. This helps identify potential documents or reports containing sensitive information.
4. Use the “inurl” operator to search for specific URLs: inurl:”admin” site:example.com. This helps identify potential administrative pages vulnerable to attack.
5. Use the “cache” operator to view the cached version of a webpage Google has indexed: cache:example.com/login.php. This provides access to the page contents even if the original page is removed or no longer accessible.
6. Use the “related” operator to find similar websites: related:example.com. This helps identify potential partners or third-party vendors with access to the company’s network.

Summary

Google Dorking is a powerful technique that allows us to perform advanced searches on Google. We can use Google Dorks to find specific information and publicly exposed vulnerabilities. It is an essential tool in a pentester’s toolkit.

Google Hacking Database (GHDB) provides a collection of pre-defined Google Dorks. Given the harm that someone can cause using dorking, it is important to use it ethically and with permission. Ensure that you have permission and follow ethical guidelines when using dorking for security audits.

Encryption works by using an algorithm to convert plaintext into ciphertext, which is unreadable without a corresponding decryption key.

This article comes from The Complete LPI Security Essentials Exam Study Guide. You can also follow along with this video:

The encryption process takes the original data, and transforms it in a way that only someone with the correct decryption key can reverse the process and read the original data. This helps ensure that sensitive information is protected from unauthorized access or interception during transmission or storage.

Understanding Encryption Tools

Encryption at rest refers to the practice of protecting data that is stored on a device, such as a hard drive or a smartphone, by encoding it using encryption algorithms. The encrypted data can only be decrypted with the appropriate key, and this helps ensure that sensitive information remains confidential even if the device is lost or stolen.

This is a common security measure used to protect sensitive information such as credit card numbers, personal data, and confidential business information.

Password hashing is a technique for storing passwords in a secure manner by converting them into a cryptographic representation called a hash. The hash is created using a one-way function that transforms the password into a fixed-length string of characters that cannot be easily reversed to reveal the original password.

$ echo -n mySecretPassword | sha256sum
2250e74c6f823de9d70c2222802cd059dc970f56ed8d41d5d22d1a6d4a2ab66f  -

Salting is a security measure added to password hashing to increase its resilience against attacks. A salt is a random value that is generated for each password and combined with the password before it is hashed.

$ openssl passwd -salt 29 mytext
$1$29$WKQPJOxDf2nJLoPwT6cnz1

This results in a unique hash for each password, even if multiple users have the same password, making it much more difficult for an attacker to use pre-computed tables of hashes (such as rainbow tables) to crack the passwords.

When verifying a password, the salt is used to regenerate the hash, which is then compared to the stored hash to determine if the password is correct.

Password Attack Tools

A rainbow table is a pre-computed table of hashes used to crack passwords by searching for a matching hash value. It is an optimization of a brute force attack that reduces the number of hashes that need to be calculated by reusing hashes computed for previous password guesses.

A Directory attack is a method of cracking passwords by using a large dictionary of words, phrases, and commonly used passwords to generate hashes and compare them to the target hashes. This type of attack is effective against weak passwords that are easily guessable.

A brute force attack is a way of cracking passwords by trying all possible combinations of characters until a match is found. It is a slow and resource-intensive method of cracking passwords, but it is effective against strong passwords that cannot be easily guessed.

Brute force attacks can be mitigated by using strong passwords, rate-limiting login attempts, and using encryption and hashing to store passwords securely.

Symmetric and Asymmetric Encryption

Symmetric cryptography, also known as shared-secret cryptography, is a type of encryption where the same key is used for both encryption and decryption of data. This means that both the sender and receiver of the data must have the same key and must keep it confidential.

Symmetric cryptography is fast and efficient but can be vulnerable if the key is compromised.

Diagram showing how symmetric encryption works

Asymmetric cryptography, also known as public-key cryptography, uses a pair of keys, one for encryption and another for decryption. The encryption key, known as the public key, can be widely distributed, while the decryption key, known as the private key, is kept confidential.

Diagram showing how asymmetric encryption works

Asymmetric cryptography is used for tasks such as digital signatures, key exchange, and data encryption, and is considered more secure than symmetric cryptography because the private key never needs to be transmitted or shared.

Hybrid cryptography is a combination of both symmetric and asymmetric cryptography.

In a typical hybrid encryption scheme, the data is encrypted using a symmetric algorithm, and the symmetric key is then encrypted using an asymmetric algorithm and sent to the recipient along with the encrypted data. The recipient uses their private key to decrypt the symmetric key, and then uses the symmetric key to decrypt the data.

Hybrid cryptography provides the security benefits of both symmetric and asymmetric cryptography, making it a commonly used encryption method.

Public Key Infrastructure (PKI)

PKI is a system for secure communication that uses a combination of public key cryptography, digital certificates, and certificate authorities (CAs) to authenticate the identity of parties involved in a communication and secure their communications.

Certificate Authorities (CAs) are organizations or entities that issue digital certificates, which are used to validate the identity of parties involved in a communication.

CAs act as trusted third parties that verify the identity of parties and issue certificates attesting to that identity. The certificate includes information such as the identity of the owner, the public key of the owner, and the digital signature of the CA.

Trusted Root-CAs are the highest level CAs in the PKI hierarchy. They are responsible for issuing certificates for intermediate CAs, who in turn issue certificates for end entities, such as individuals or organizations.

The trustworthiness of the entire PKI system is based on the trust in the root CAs. A trusted root CA is one that is widely recognized and trusted by users, systems, and applications.

The trusted root CA's certificate is usually pre-installed in software and devices, such as web browsers, to facilitate secure communication and verify the authenticity of digital certificates issued by other CAs.

Wrapping Up

With what you've learned here, you're now ready to use encryption tools like VeraCrypt and GnuPG to protect the data you store on your local machines. You'll be able to properly assess the safety and integrity of the online and cloud storage platforms where you store data remotely.

This article and the accompanying video are excerpted from my Complete LPI Security Essentials Exam Study Guide course. And there's much more technology goodness available at bootstrap-it.com

Online frauds and scams have shot past projections in the last decade, and no one seems to be immune to them—including developers.

The shift to serverless cloud management has opened doors for hackers to try new attack surfaces and the impact is right in front of us. 90% of web applications are vulnerable to cybercriminals, and a majority of these vulnerabilities can be traced back to direct dependencies.

Thanks to cloud migrations, DevOps teams can roll out product iterations faster and improve customer management KPIs. But this also means they lose control over custom code infrastructure and servers. Companies that have traded custom security for cloud efficiency are more susceptible to cybercriminals today.

In this article, we'll look into the most common scams faced by developers, how they work, and what developers can do to mitigate the risks.

What is a Fraud or Scam?

Fraud is the illegal attempt to deceive a person, entity, or organization to gain access to confidential assets.

Scams are the smaller steps that help criminals commit fraud and they almost always involve money.

If you have been scammed there's a good chance you've lost money. Frauds, however, may not always lead to financial ruin as the impact can be much larger than that.

DevOps teams are increasingly vulnerable to fraud and scams because these are built on deception and social engineering. Since access management is a major security pitfall of modern IT development, fraudsters look to access developers’ credentials to compromise systems and steal money and information.

Four Common Scams and How They Work

Hackers today use precise strategies to create the biggest impact. They have gone from “tried and tested” to highly targeted and innovative attacks that end up fooling even the most security-aware victims such as developers.

To better understand how these work here are a few examples:

1. DDos Attacks

Distributed denial-of-service (DDoS) attacks are one of the most common types of cyberattacks that plague developers today. With a DDoS attack, criminals try to overwhelm a network or web application by sending a huge amount of access requests, effectively shutting it down.

Since most businesses today rely on their digital infrastructure to operate, an offline website or application at crucial moments can lead to massive loss—both financial and reputational.

DDoS attacks use compromised machines and IoT devices as zombies (or bots) to send millions of pings within a short amount of time. Attackers can target the server architecture by spoofing SYN data packets, stress the software resources by using HTTP flood, or dump huge traffic on the website with DNS amplification.

Since it's difficult to detect botnet requests from authentic requests, victims often have a hard time separating the two. On top of that, the distributed nature of the attack means blocking off one IP address won't solve the issue.

Weird TTL responses with odd values which obviously tell you they did not come from the original server, but rather some intermediate device. Source

One of the most famous examples of DDoS attacks was the 2015 attack on GitHub by Chinese attackers. It started with injecting browsers used to visit Baidu and Baidu analytics-enabled websites with JavaScript code run by a telecom company called China Unicom.

The malicious code created a botnet of affected browsers and triggered the browsers to send a massive amount of HTTP requests to specific GitHub pages. The attack lasted for five days and many parts of GitHub were inaccessible.

2. Credit Card Scams

DevOps teams often have a lax attitude towards financial compliance, making them a gateway to credit card scams. These types of scams either look to get ahold of employee credit cards or gather enough data to carry out card-not-present (CNP) frauds.

Credit card scams can happen in several ways and attackers are still trying new methods to deceive victims.

It can start with simple shoulder surfing where an attacker monitors you entering the PIN or showing card details to advanced keyloggers and card skimmers placed at shady ATMs. Fake charities and rewards are also popular ways to get hold of credit card details.

On top of that, criminals can use personally identifiable information (PII) to apply for a new credit card or request updates to your old card and block it. They can go as far as intercepting cards from the mail or assaulting victims to steal credit cards.

Even if they don't get ahold of your card, CNP frauds allow them to make huge transactions online, which might ruin the victim’s credit score and put their finances in a tough spot.

3. SIP Trunking Fraud

Modern business communication relies on VoIP phone systems to reach customers, vendors, and stakeholders and uses omnichannel flexibility to improve productivity. It all sounds great on paper but VoIP used by small businesses often falls victim to SIP trunking fraud.

Session initiation protocol (SIP) trunk is the technology that connects a company's existing phone system or PBX with the cloud, allowing VoIP to work across the globe. It's a crucial piece of technology that is often exploited by hackers. Here's how it usually goes down:

• Cybercriminals use IP scanners to look for vulnerable phone systems to gain access to the SIP trunks
• They either steal passwords or use brute force attacks on weak systems
• Once they have the access, attackers often spoof caller IDs to extract sensitive data such as credit card and login details or eavesdrop on texts and calls on public IP connections.
• Apart from this, attackers might commit toll fraud by rerouting calls to virtual phone numbers in premium domestic and international territories and stealing the revenue earned from those calls.

Twilio is flagging fraudulent calls by using their 3rd party anti-fraud database. Source

If SIP trunking fraud is left unchecked, a business can lose thousands of dollars within a few hours.

4. SIM Swapping

SIM swapping can happen to anyone and developers have no additional security against these types of scams. SIM swapping is convincing your network provider to transfer your SIM to their device, effectively taking over your phone number and everything tied to it.

SIM swapping doesn't happen in a vacuum—it requires long-term planning and social engineering. Here's how it works:

• A scammer calls your SIM provider and requests to transfer the phone number because they claim the device is destroyed or stolen.
• Now the representative asks for ID proof to authenticate the transfer and it usually requires personal information such as an address, email ID, IMEI, or last four digits of the credit card.
• If the scammer can prove your identity to fool the operator, they can activate a new SIM in their phone.

This is where long-term strategies come into play. Before executing a SIM swap, attackers use phishing emails, malware, and data breaches to collect snippets of personal data and piece them together to convince the SIM provider.

_Example of a SIM Swapping scam text message. Source_

A few years ago, a disgruntled T-Mobile employee exposed customer data to hackers who would swap out SIM and take over accounts.

Once the attackers have your SIM, they can bypass two-factor authentication (2FA) for all transactions, and get hold of your bank details, SSN, and personal media. SIM swap opens the floodgates to all kinds of crimes that require your phone number in the first place.

How DevOps Can Prevent Fraud and Scams

Security risks come in abundance but developers are familiar with the concepts. By following a few steps you can detect, address, and mitigate most of these scams.

How to Prevent DDoS Attacks

DDoS attacks are hard to distinguish without harming real traffic, which makes mitigation a difficult job. But you still try a few methods.

1. Detect signs of a DDos attack

Know the symptoms of DDoS to detect attacks early on. If an online asset is suddenly slow or unresponsive, you might have to look for DDoS signs. These include:

• an unusually high volume of traffic at odd hours of the day
• hordes of requests coming from the same IP address, location, device, or browser, and targeting a specific page or part of the application.

You can react quickly if you have monitored and documented the usual traffic patterns of your company.

2. Deploy anti-DDoS measures.

Start by using hardware and applications that are built to prevent DDoS attempts and restore assets, decentralizing data centers and servers, using a web application firewall (WAF), and migrating to the cloud to increase bandwidth.

AWS Shield Advanced is an easy-to-configure managed DDoS protection service that can detect and mitigate large-scale and complicated attacks.

Apart from using anti-DDoS tools, you should also close security loopholes in your network and practice cyber hygiene daily.

Example of AWS configuration for DDoS mitigation. Source

3. Have a DDoS response plan in place to prevent further damage.

This should include documented steps, a well-prepared team, and clear communication channels for internal and external stakeholders.

Modern multi-factor DDoS attacks combine multiple pathways so the more complex and thorough your plans are the better you can protect the company.

How to Prevent SIP Trunking Scams

SIP trunking is a common method of phone fraud, but you have some weapons in your armory to prevent these.

1. Set up a maximum default rate for outbound calls to prevent toll fraud.

When you set a limit for the number of calls, you'll be notified if your business crosses that threshold—allowing you to monitor calls made by hackers.

On top of that, use a solid VoIP service to identify outbound and inbound calls and log as much information as possible. Hackers will call to and from random numbers so it becomes easier for you to set up call barring for suspicious numbers.

VOIP vendor settings to disallow inbound calls which have characterists of robocalls. Source

2. Activate IP-based authentication to manage network access.

With this enabled, users would need to be part of your network to make and receive calls. Even though IP addresses are not completely hidden, you'll be notified of any effort to breach your network. By mandating a static IP address, you can easily set up IP-based authentication and monitor calls.

3. Reinforce PBX security.

You can protect your phone system by using new and complex passwords, regularly changing and storing them safely, properly installing SBC configuration, and using TLS and SRTP for superior encryptions. On top of that, you should also restrict access to hardware to prevent data breaches.

How to Prevent Credit Card Scams

Credit card scams can open Pandora's box and as a developer, you should be wary of the consequences. Here are some steps you can take to prevent credit card scams:

1. Employees using company credit cards are the easiest victims of scams.

You can help them mitigate the risks with training. A series of training modules and frequent seminars should include identifying ways credit card details can be stolen (as discussed above) and quickly acting in case of theft.

These should also encourage employees to access only HTTPS websites, use VPNs every time they use personal devices or public WiFi, and help them identify malware and phishing attempts.

On top of that, you should use an identity theft protection service to limit the consequences of credit card scams.

2. As a developer, you're bound by compliance standards (and ethics) to secure the credit card details of employees and customers.

While writing code for software meant to process and store credit cards, you should distribute duties to protect yourself and the business. Not many developers follow the PCI DSS guidelines regarding this and trap themselves in compliance red tape.

PCI DSS sections 6,7 and 8 clearly lays out third-party code review rules along with role and access management. Following compliance standards and leaving access keys to admin are best practices to mitigate potential credit card scams.

How to Prevent SIM Swapping

SIM swapping starts long before convincing SIM providers to activate a new SIM which is why you have to take several measures:

1. Phishing and other social engineering methods are used to mimic you, so be wary of these crimes.

Be on the lookout for phishing emails and SMSs, malware injections, compromised websites, and fake calls that coax you into sharing personal details such as birthdays, physical and email addresses, and SSNs. Scammers use this information while calling your operator.

Another way you can prevent this is by limiting how much personal data you share online in the first place. Here’s an example of a nicely crafted phishing email impersonating PayPal. All you have to do is check the sender’s address to find the scam

Example of a Paypal Scam. Source

2. Don't make your phone number the central part of your security.

Since SMS is not a secure mode of 2FA in case of device theft and SIM swapping, use biometrics such as fingerprint or face IDs and authentication apps such as Authy to protect 2FAs.

Speaking of third-party apps, you should also use a password manager to create and maintain unique, complex, and 14-character-long alphanumeric passwords to make sure attackers cannot use your personal information to guesstimate logins.

3. Activate alerts so that banks can monitor when your SIM is reactivated on an unknown device.

Work with businesses that use callbacks to verify identities for transactions and don't forget to activate the PIN lock by the carrier to prevent unauthorized porting.

Final Word

Cybercrimes and social engineering tactics have grown by leaps and bounds and developers working on critical projects must make sure they don't become a security liability.

By following the above steps you can protect your employer, colleagues, and yourself from nasty surprises.