Like most developers, I installed a library, called a hash function, stored the result, and moved on. I see a random string like \(2a11yMMbLgN9uY6J3LhorfU9iu.... in my database and assume my user's passwords are unbreakable. I knew it was a hashed password. But what was the \)2a? What was 11? And if I couldn't reverse it, how was my app verifying logins at all?

If you've ever used bcrypt, Devise, Django's auth system, or really any authentication library, you've been protected from these details. That's good engineering. But understanding what's actually happening makes you a better developer, and it explains a lot of things that seem confusing or arbitrary until suddenly they don't.

By the end of this article, you'll be able to look at that string and know exactly what every part means.

Prerequisites

This article is written for developers who have used an auth library before but never looked closely at what it's doing. You don't need a cryptography background. If you've ever hashed a password and moved on, this is for you.

Table of Contents

1. Hashing vs Encryption

2. Why a Plain Hash Isn't Enough

3. Enter Salting

4. Why bcrypt Is Slow (and Why That's the Point)

5. What's Actually in Your Database

6. Wrapping Up

Hashing vs Encryption

Most developers use the terms hashing and encryption interchangeably. They're not the same thing, and the difference matters more than you might think.

Encryption is a two-way process. You take data, encrypt it with a key, and you can decrypt it later using that same key (or a related one). This is useful when you need to retrieve the original value. Storing a credit card number you'll need to charge later, or sending a message that the recipient needs to read.

Hashing is different. It's a one-way process. You put data in, you get a fixed-length string out, and there's no key that lets you reverse it. The original value is gone.

That might sound like a limitation. For passwords, it's actually exactly what you want.

Think about it: when a user logs in, you don't need to know their password. You just need to verify that what they typed matches what they set when they signed up. You can do that entirely with hashes. Hash what they typed, compare it to the stored hash, done. You never need the original.

This is why "forgot password" flows always ask you to set a new password rather than sending you your old one. Yes, sending you your old password over email might be risky but the actual reason is that they genuinely can't retrieve it. If they can email you your original password, that's a red flag. It means they stored it in a way that's reversible, which means it's not properly protected.

Why a Plain Hash Isn't Enough

So if hashing is one-way and irreversible, isn't that enough? Just hash every password before storing it and you're done?

Not quite.

The first problem is rainbow tables. A rainbow table is a precomputed database of hashes for common passwords. An attacker who gets hold of your database doesn't need to reverse the hashes. They just look them up. If your user's password is "password123", its SHA-256 hash is always the same string, and that string is almost certainly already in a rainbow table somewhere.

The second problem is related. If two users have the same password, they'll have the same hash. So if an attacker cracks one, they've cracked all of them. In a database with thousands of users, that's a significant security risk.

Here's what that looks like in practice:

import hashlib

# Two users, same password
password = "password123"

hash_one = hashlib.sha256(password.encode()).hexdigest()
hash_two = hashlib.sha256(password.encode()).hexdigest()

print(hash_one == hash_two)  # True, every single time

The hash is deterministic. The same input always produces the same output. That's useful for a lot of things, but for passwords it creates a real vulnerability.

A plain hash gets you partway there. But it's not enough on its own.

Enter Salting

The fix for both problems is something called a salt. And, no it's not your regular table salt.

A salt is a random string generated uniquely for each password. Before hashing, you combine the salt with the password, then hash the result.

import hashlib
import os

password = "password123"

# Generate a random salt
salt = os.urandom(16).hex()

# Combine salt and password, then hash
salted_password = salt + password
hashed = hashlib.sha256(salted_password.encode()).hexdigest()

print(f"Salt: {salt}")
print(f"Hash: {hashed}")

Now two users with the same password produce completely different hashes, because their salts are different. And because the salt is random and unique, it can't be precomputed into a rainbow table.

Here's the surprising part: the salt doesn't need to be secret. It gets stored alongside the hash in your database, in plain text. That might feel wrong at first. If an attacker has your database, they have the salt too.

But that's fine. The salt's job isn't to be secret. Its job is to make each hash unique so that precomputed tables are useless. An attacker who wants to crack a salted hash has to brute force each password individually, from scratch, using that specific salt. They can't reuse work across users.

That's a meaningful increase in the cost of an attack, even when the salt is visible.

Why bcrypt Is Slow (and Why That's the Point)

Salting solves the rainbow table problem. But there's still a gap. If an attacker has your database and decides to brute force a password, they can just keep guessing. Hash a candidate password with the stored salt, compare it to the stored hash, repeat. With a fast hashing algorithm like SHA-256, a modern GPU can do billions of these comparisons per second.

That's the problem with using a general-purpose hash function for passwords. Algorithms like SHA-256 and MD5 were designed to be fast. That's great for things like verifying file integrity or generating checksums. For passwords, it's a liability.

This is where bcrypt comes in. bcrypt is a password hashing algorithm designed specifically to be slow. Not broken or inefficient by accident, but deliberately, configured-to-be slow. It has a cost factor (sometimes called a work factor) that controls how computationally expensive the hashing operation is.

import bcrypt

password = b"password123"

# The cost factor is set here (12 is a common production value)
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

print(hashed)

Every time you increase the cost factor by 1, the hashing operation takes roughly twice as long. At a cost factor of 12, a single hash might take around 300 milliseconds on your server. That's imperceptible to a user logging in. But for an attacker trying to brute force millions of passwords, it turns a feasible attack into an impractical one.

The other advantage of a configurable cost factor is that you can increase it over time as hardware gets faster. What was slow enough in 2015 might not be slow enough today. bcrypt lets you adapt without changing the algorithm itself.

What's Actually in Your Database

So far, we've talked about salting and cost factors as separate concepts. Here's the satisfying part: in bcrypt, they're all stored together in a single string. That string sitting in your database contains everything needed to verify a password, and once you know how to read it, it's not mysterious at all.

Here's a typical bcrypt hash:

\(2a\)12$yMMbLgN9uY6J3LhorfU9iuLAUwKxyy8w42ubeL4MWy7Fh8B.CH/yO

Let's break it down:

• $2a — the algorithm version. This tells your auth library which version of bcrypt was used to generate the hash.

• $12 — the cost factor. This is the number we talked about in the previous section. A cost factor of 12 means the hashing operation was run 2¹² times.

• \(yMMbLgN9uY6J3LhorfU9iu — the salt. The first 22 characters after the final \) are the salt, stored right there in plain text alongside the hash. Your auth library reads this back out when verifying a login.

• LAUwKxyy8w42ubeL4MWy7Fh8B.CH/yO — the hash itself. The remaining characters are the actual output of the hashing operation.

When a user logs in, your auth library doesn't need any extra information. It reads the algorithm version, cost factor, and salt directly from the stored string, hashes the login attempt using those same parameters, and compares the result. If they match, the password is correct.

This is why bcrypt verification works even though the salt is never stored separately. It was never separate to begin with.

Wrapping Up

Next time you see a bcrypt string in your database, you'll know exactly what you're looking at. The algorithm version, the cost factor, the salt, and the hash, all encoded in a single string that your auth library knows how to read.

But the bigger takeaway is this: the libraries we rely on every day aren't magic. They're carefully designed systems built on top of concepts that are worth understanding.

Knowing why bcrypt is slow, why salting works even when the salt is visible, and why fast hash functions like SHA-256 are the wrong tool for passwords makes you a more intentional developer. You'll make better decisions about cost factors, you'll recognise a poorly implemented auth system when you see one, and you'll understand why a data breach where passwords were hashed with MD5 is so much worse than one where bcrypt was used.

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

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

What is WebAuthn? 😅

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

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

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

WebAuthn is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others.

Web Authentication works hand in hand with other industry standards such as Credential Management Level 1 and FIDO 2.0 Client to Authenticator Protocol 2.

How Does WebAuthn Work? 🤔

So like every other login situation:

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

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

Generic WebAuthn Flow

Registration Flow

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

There is a simple 8 step process that takes place:

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

Registration Flow

The WebAuthn Authentication Flow

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

There is a simple 8 step process that takes place:

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

Authentication Flow

Benefits of WebAuthn

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

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

and lastly NO MORE PASSWORDS.

Disadvantages of WebAuthn

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

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

Note — this doesn’t replace things like token-based authentication flows like OAuth or OIDC or identity providers like Auth0, Okta, Google, and others.

Conclusion

WebAuthn is a much more secure authentication flow than simply using a password. It is phishing resistant and only stores public data on a database with most private data generally stored on the hardware authenticator only.

It makes use of asymmetric cryptography to do a user check and provides a much better UX compared to the existing login flow.

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

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

Thanks for reading! I really hope that you find this article useful. I’m always interested to know your thoughts and happy to answer any questions you might have in your mind. If you think this post was useful, please share it so others can see it, too.

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

In this guide, I will show you a great way to password protect a zip file, so you can be rest assured only those who should see it have access to it.

First, What is a Zip File?

A zip file, also called a zip folder, helps you compress multiple files into one giant file. This lets you easily save them in one file, or send them across to anyone you want in one go. Zip files have .zip as their extension.

In addition to being able to squeeze down multiple files into one, you also get the advantage of reduced file size and being able to protect the zip file with a password.

How to Password Protect a Zip File on Windows 10

Windows 10 only offers a way to encrypt a zip file, not password protect it. So, to password protect a zip file on Windows 10, you need a third-party app that runs on Windows. An example of such a third-party app is WinRAR.

How to Password Protect a Zip File with WinRAR

Step 1: The first thing you need to do is download WinRAR from its official website.

When you download the installer (usually with a .exe extension), open it up and follow the installation wizard to install WinRAR.

Step 2: Open the Zip file with WinRAR

Step 3: From the menu items, select "Tools" and choose "Convert archives". You can also press Alt + Q on your keyboard to quickly do this.

Step 4: Click on the "Compression..." button from the pop-up that appears.

Step 5: Click on "Set Password..." in the next pop-up that appears.

Step 6: Input the password of your choice in the "Enter password" field, and confirm it in the "Reenter password for verification" field and click “Ok”.

Step 7: Click “Ok” again. A pop-up will appear asking if you want to encrypt converted archives. Click on Yes.

Step 8: Click “Ok” once again. WinRAR will now go through the process of protecting your zip file with the set password. The larger the file, the longer it takes.

After it's done, click on the Close button and that's all.

You will now have a separate zip file with the .rar extension. This is the one that will be protected with a password.

How to Password Protect a Zip File with 7-Zip

Another third-party app for protecting your zip files with passwords is 7-Zip.

Go through the steps below to password protect your zip files with 7-Zip.

Step 1: Download the 7-Zip app from their website and install it.

Step 2: Right-click on the folder you want to zip and hover over the 7-Zip option. In the menu that appears while you're hovering, select "Add to archive".

Step 4: In the "Encryption" section, enter your desired password in the "Enter password" field and confirm it in the "Reenter password" field.

Step 5: Click on "Ok" to finally create the zip file and protect it with a password.

Conclusion

Since you can compress multiple files into one giant zip folder, you might need to protect it with a password. This makes sure that only those who have access can open the zip file.

I hope this guide helps you password protect your zip files. If you find it helpful, please share with your friends and family.

Thank you for reading.

Passwords are often paired with usernames or email addresses to identify specific users.

For good security, your passwords should be long, difficult to guess, but easy for you to remember. Your passwords should also be unique to each account or website. That way, if one of your passwords is leaked, all your other passwords are still secure.

Because it's very difficult to create and remember secure, unique passwords, it's recommended to use a password manager. Popular password managers include Bitwarden, 1Password, and LastPass.

You an read more about password managers and online security here.

Related Tech Terms:

• Username Definition

There are tons of new apps launching every day, so you'll want to make yours stand out. It should have unique features, and it should be easy and convenient to use.

One of the major pain points for many apps is that they require a username and a password to login. I personally have to remember 10-15 passwords for apps like Gmail, Facebook, Instagram, and more. You get the idea.

In this article we are going to create a solution for your APIs that will allow your users to login without a password.

How to go password-less

In order to omit the need for a password, your app should generate some type of token for the user.

This token then gets sent to the user where only they can access it – for example in their email or via their phone. Here is an overview of the flow.

.NET Identity is a package which provides ways to manage users, passwords, profile data, roles, claims, tokens, and more.

In addition, Identity provides ways to generate tokens for email confirmation or for changing the user's email or phone. We will be using the tokens generated by Identity to verify our users.

There are two main token providers available:

• TotpSecurityStampBasedTokenProvider (Time-based One Time Password).
• DataProtectionTokenProvider

TotpSecurityStampBasedTokenProvider

This token provider generates time-based tokens which are valid for around 3 minutes (you can reference the source code here). Based on the token provider, the tokens are generated from the email, phone number, or user id as well as the user's security stamp.

Dotnet Identity provides the utility classes EmailTokenProvider and PhoneNumberTokenProvider that are subclasses of TotpSecurityStampBasedTokenProvider.

DataProtectorTokenProvider

If you want to generate a token that doesn't expire for a long time, DataProtectorTokenProvider is the way to go.

DataProtectorTokenProvider generates tokens using a DataProtector and cryptographic algorithms. You can check out the implementation for more details here.

In this article we are going to subclass DataProtectorTokenProvider so that our token is valid for 10 minutes.

How to Set Up Identity

Let's start with a new project. Create a project by executing the command dotnet new webapi –-name NoPasswordProject.

dotnet add package Microsoft.EntityFrameworkCore.InMemory --version 5.0.4
dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore --version 5.0.4

We are going to create an in-memory database for this tutorial. But you can use a database of your choice and accordingly change the package above.

Note: The in memory database will clear the users every time the server restarts.

How to Create a Custom Token Provider

Let's create a custom token provider that generates tokens that are valid for 10 minutes.

NPTokenProvider

Create a new file called NPTokenProvider.cs. The NP prefix stands for No Password.

using Microsoft.AspNetCore.DataProtection;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

public class NPTokenProvider<TUser> : DataProtectorTokenProvider<TUser>
where TUser : IdentityUser
{
    public NPTokenProvider(
        IDataProtectionProvider dataProtectionProvider,
        IOptions<NPTokenProviderOptions> options, ILogger<NPTokenProvider<TUser>> logger)
        : base(dataProtectionProvider, options, logger)
    { }
}

Here we're subclassing the DataProtectorTokenProvider. Nothing out of the ordinary, except in the constructor we are passing NPTokenProviderOptions. The options need to be subclasses of DataProtectionTokenProviderOptions.

NPTokenProviderOptions

Create a new file called NPTokenProviderOptions.cs and paste in the below code.

using System;
using Microsoft.AspNetCore.Identity;

public class NPTokenProviderOptions : DataProtectionTokenProviderOptions
{
    public NPTokenProviderOptions()
    {
        Name = "NPTokenProvider";
        TokenLifespan = TimeSpan.FromMinutes(10);
    }
}

We are setting options for the tokens to be created. You can change the Name and TokenLifeSpan to your liking.

DbContext

Almost every project needs a database to store its users and other data related to the project. The Dotnet EF Framework provides a nice helper DbContext to handle sessions with the database and query and save entities.

So create a subclass of IdentityDbContext which is in turn a subclass of DbContext. Name the file NPDataContext.cs.

using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;

public class NPDataContext : IdentityDbContext
{
    public NPDataContext(DbContextOptions<NPDataContext> options)
        : base(options)
    { }
}

Startup.cs

We have created the classes. Now it's time to configure them in our Startup.cs files. In ConfigureServices add the below code at the start.

var builder = services
.AddIdentityCore<IdentityUser>()
.AddEntityFrameworkStores<NPDataContext>();

var UserType = builder.UserType;
var provider = typeof(NPTokenProvider<>).MakeGenericType(UserType);
builder.AddTokenProvider("NPTokenProvider", provider);

services.AddDbContext<NPDataContext>(options =>
    options.UseInMemoryDatabase(Guid.NewGuid().ToString()));

services.AddAuthentication(options =>
{
    options.DefaultScheme = IdentityConstants.ExternalScheme;
});

Also add app.UseAuthentication(); above app.UseAuthorization(); in the Configure method.

NoPasswordController.cs

Let's create a controller for our login and verify the APIs. Create a NoPasswordController.cs file in your Controllers folder. Add the below content to the file.

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Mvc;

namespace NoPasswordProject.Controllers
{
    [ApiController]
    [Route("[controller]/[action]")]
    public class NoPasswordController : ControllerBase
    {
        private readonly UserManager<IdentityUser> _userManager;

        public NoPasswordController(UserManager<IdentityUser> userManager)
        {
            _userManager = userManager;
        }
    }
}

We are injecting an instance of UserManager in our controller. UserManager is used for CRUD operations for a user as well as generating tokens and validating them.

Login API

Let's add a Login API which accepts an Email as input. The Email is the unique identifier for a user, that is there should be a one-to-one relationship between user and email.

Create a new function in your controller as below.

[HttpGet]
public async Task<ActionResult<String>> Login([FromQuery] string Email)
{
    // Create or Fetch your user from the database
    var User = await _userManager.FindByNameAsync(Email);
    if (User == null)
    {
        User = new IdentityUser();
        User.Email = Email;
        User.UserName = Email;
        var IdentityResult = await _userManager.CreateAsync(User);
        if (IdentityResult.Succeeded == false)
        {
            return BadRequest();
        }
    }

    var Token = await _userManager.GenerateUserTokenAsync(User, "NPTokenProvider", "nopassword-for-the-win");

    // DON'T RETURN THE TOKEN.
    // SEND IT TO THE USER VIA EMAIL.
    return NoContent();
}

Here we are fetching a User from the database. If the user doesn't exist then we create a user. Make sure to set the UserName as well or it will give a runtime error.

Then based on the user, we generate a UserToken. The GenerateUserTokenAsync takes the user, token provider, and the purpose for generating a token.

The token provider string should be the one you have used in NPTokenProviderOptions. The purpose can be anything you want.

Send out the token to the user via a link in a nicely designed email. When the user clicks on the link in the email it will open your front-end page. Consequently this page will request the Verify API.

Verify API

Let's add another API called Verify that takes the Email and Token as query parameters.

[HttpGet]
public async Task<ActionResult<String>> Verify([FromQuery] string Token, [FromQuery] string Email)
{
    // Fetch your user from the database
    var User = await _userManager.FindByNameAsync(Email);
    if (User == null)
    {
        return NotFound();
    }

    var IsValid = await _userManager.VerifyUserTokenAsync(User, "NPTokenProvider", "nopassword-for-the-win", Token);
    if (IsValid)
    {
        // TODO: Generate a bearer token
        var BearerToken = "";
        return BearerToken;
    }
    return Unauthorized();
}

We are again fetching the user based on email. As a result, if we are not able to find the user we'll return 404 Not Found.

We then continue to verify the user. VerifyUserTokenAsync takes user, token provider, purpose, and token as input parameters. The purpose should be the same as the one used while generating the token.

If the token is not valid, return 401 Unauthorised. Otherwise return the bearer token. This is a good article on how to generate a bearer token for the user.

You can find the whole project here.

Conclusion

Good features used to be the main thing that mattered when creating an app. But today, besides having great features convenience is a priority for users.

In this article, we looked at one way you can make your apps more user-friendly. Let me know if you have other ways to improve your apps.

Check here for more tutorials like this.

Passwords are often used to protect sensitive information in a PDF document, or to prevent someone from easily editing it. That's great – it's good to know that whoever created the document is going the extra mile to protect your privacy.

The problem with a password protected PDF is that you need to enter the password every time you want to open the document. If you have multiple password protected PDFs, safely storing and managing all those different passwords can be a real hassle.

If you've ever wondered how to remove a password from a PDF to make it easier to open and share, read on.

Important note: To remove a password from a PDF, you must know what the password is beforehand. This guide is about convenience, and not for cracking or brute forcing an unknown PDF password.

Print to another PDF file

The most convenient way to remove password protection from a PDF is to open it, then print it as another PDF file. The new PDF file will not be password protected, and you'll be able to open it without having to enter the original password.

While this works in most free PDF readers, using a browser like Google Chrome is very easy, and works the same across all major operating systems.

First, open the password protected PDF in Chrome by opening a new tab and dragging the file into the browser. You could also right click on the PDF and select "Open with" and "Google Chrome", though this may differ slightly depending on your operating system.

You'll be prompted for the password. Enter the password, then click the "Submit" button:

Once the document is open, bring up Chrome's print menu by clicking the print button in the upper right-hand corner. Alternatively, just press Ctrl + p for Windows and Linux or Cmd + p for macOS:

With the print menu open, make sure "Destination" is set to "Save as PDF". Then click "Save" in the lower right-hand corner:

Rename the file if you wish and save it.

Then when you open the new file you won't be prompted for a password:

Finally, store your new PDF file somewhere safe. And be careful whom you share it with if it contains any sensitive information.

TL;DR

Here's a CliffsNotes version of the steps above:

• Open the password protected PDF file in Google Chrome
• Enter the password when prompted
• Open the print menu, select "Save as PDF", and click the "Save" button
• Rename the file if you want to and save it somewhere that's secure

And with that, you should be able to quickly and easily remove password protection from any PDF in Windows, macOS, and Linux.

Stay safe and happy password removing :)

A brief note - this article is about the theory of how to crack hashed passwords. Understanding how cybercriminals execute attacks is extremely important for understanding how to secure systems against those types of attacks.

But attempting to hack a system you do not own is likely illegal in your jurisdiction (plus hacking your own systems may [and often does] violate any warranty for that product).

This article assumes some level of knowledge of hashing functions and basic password cracking techniques - if you don't understand those topics, check out these articles.

So, you've obtained a set of hashed passwords. Brute forcing the hash will take a very long time. How can you speed up this process?

Wait, I thought hash functions were one-way! How do you crack hash functions?

Unfortunately, the hashing functions which are used for hashing passwords aren't always as secure as generally approved hash functions. For example, the hashing function used for old Windows devices is known as LM Hash, which is so weak that it can be cracked in a few seconds.

Also, you don't need to reverse engineer the hash. Instead, you can use a pre-computed set of plaintext passwords and the corresponding hash value (, ). This tells a hacker what plaintext value produces a specific hash.

With this you'll know what plaintext value produces the hash you're looking for. When you enter a password the computer will hash this value and compare it to the stored value (where it will match) and you'll be able to authenticate. Thus, you don't actually need to guess someone's password, just a value which will create the same hash.

This is called a collision. Essentially, as a hash can take data of any length or content, there are unlimited possibilities for data which can be hashed.

Since a hash converts this text into a fixed length content (for example, 32 characters), there are a finite number of combinations for a hash. It is a very very large number of possibilities, but not an infinite one.

Eventually two different sets of data will yield the same hash value.

Precomputed tables are very helpful in achieving this, as they save significant time and computing power. Using a pre-computed set of hashes to look up a password hash is called a 'lookup-table attack'. These tables are used by system administrators to test the strength of their users' passwords, and are often available online or for purchase. However, they can also be used by nefarious hackers.

If a password is insecure (let's say someone uses a password 5 characters long), it can be relatively easily cracked. For example, a password of 5 lowercase characters can only be used to create 11,881,376 different passwords (26^5).

For a hash of this password, even if the hash is cryptographically secure (uses an appropriate algorithm), it would still be very easy to compute all possible passwords and their corresponding hashes. Lookup tables work very well for these types of password hashes.

However, as passwords increase in length, the storage (and therefore storage cost) you need for every possible password and the corresponding hash grows exponentially.

For example if the password you're trying to crack is 8 characters long but uses numbers (10 digits), lowercase letters (26), uppercase letters (26), and some special characters (10), the number of possible passwords jumps to 722,204,136,308,736 - which is A LOT of storage space, when you realize each is hashed with a hashing function like SHA-256.

Rainbow tables address this issue by offering reduced storage needs, but they take more time to compute the potential passwords. At the most basic level, these are essentially pre-computed lookup tables which enable you to quickly find the plaintext which matches the hash you have. If the hash and plaintext are contained in the table you have - similar to dictionary attacks - you're only looking to see if the password is contained in the table you have. If it isn't, you won't be able to crack the password. You can find these online for free or for purchase.

Check out this article for a tutorial on creating your own rainbow tables.

I'm still interested. How do rainbow tables work?

If you want to skip the detailed explanation of how these work, feel free to scroll down to the 'How to protect against these attacks' section.

In order to save yourself from hashing and storing each possible plaintext until you find the hash you need (like a lookup table), you hash each plaintext and store the result in a table to look up later without having to regenerate them. This takes longer, but saves memory.

To generate the table, you create 'chains' of hashes and plaintext using a hashing function and a reduction function. A reduction function just creates plaintext from a hash (it doesn't reverse engineer the hash, but rather creates different plaintext from the hash). It is also a one-way function.

Thus in order to compute the table, you use one of your hashes, h1, in your reduction function, R(), in order to create the plaintext p1.

R(h1) = p1.

Then you use the hash function H() with p1 to create a new hash.

H(p1) = h2.

Using our example from before:

If the set of plaintext is [abcdefghijklmnopqrstuvwxyz]{5} (we're looking for a rainbow table of all passwords composed of lowercase letters of length 5) and we're using MD5 (a hashing algorithm):

A hash might be ab56b4d92b40713acc5af89985d4b786 (h1). Now, we apply the reduction function, which could be as simple taking the last 5 letters in the hash.

R(ab56b4d92b40713acc5af89985d4b786) = cafdb

H(cafdb) = 81a516edabf924cd0f727d329e855b1f

Why are they called rainbow tables?

Each column uses a different reduction function. So if each column were colored, it would be a very long, skinny rainbow.

Using different reduction functions reduces the number of chain merges (collisions) which happened frequently with hash-chains, the predecessor to rainbow tables. This essentially means that if you keep using the same reduction function, there's a chance you'll end up with two different chains which converge to the same plaintext. Using different reduction functions reduces the chance of this happening, though it isn't impossible.

Great, how do you create a chain?

In order to create a chain, you're using your reduction function and hashing function (both one way) to create a 'chain' of hashes and plaintext. Each of these 'chains' would continue for k steps, and when the chain ends, will store only the first plaintext and the last hash in the chain.

So, a sample chain looks like this:

p1 -> h1 = H(p1) -> R1(h1) = p2 -> H(p2) = h2 -> R2(h2) = p3 -> H(p3) = h3

Each reduction function is different (represented by R1, R2, R3, etc.) A sample table of chains (each row is a chain of length 5) looks like the following. Note that this is populated with fake data just to give you an example - the hashing function isn't a hash function you would find used to hash passwords.

The reduction functions, R1 and R2 are defined as follows – R1 takes the first 3 digits of the hash, and R2 takes the last 2 letters of the hash:

p1 -> h1 = H(p1) -> R1(h1) = p2 -> H(p2) = h2 -> R2(h2) = p3 -> H(p3) = h3

2 -—> abdu2934 -—> 293 -—> 83kdnif8 -—> if -—> ike83jd3

15 -—> dks2ne94 -—> 294 -—> ld932nd9 -—> ld -—> ldie938d

20 -—> ld93md8d -—> 938 -—> lxked93k -—> lx -—> 93mdkg8d

In a rainbow table, only the first starting point and the endpoint are saved to save on storage, like this:

starting point (plaintext) endpoint, after k steps through the chain (hash)

p1 -—> h1k

p2 -—> h2k

p3 -—> h3k

Then when you have a hash (h) where you don't know the plaintext (?), you'll compare it to the chains.

1. First, you'll check if the hash is in the list of final hashes (h1k, h2k, etc.). If so, you can move to step 3.
2. If not, you can reduce the hash to different plaintext (R1) and then hash that plaintext (using the hash function and next reduction function above) and compare it to the list of final hashes (h1k, h2k, h3k, etc.). When it matches one of the final hashes, that chain will likely contain the original hash.
3. In order to find the original hash in the chain, take that chain's starting plaintext (so if it matches h1k, start with p1) and apply the hashing and reduction functions to move along the chain until you reach the known hash and its corresponding plaintext. This way you can move through the hashes in the chain without having them take up storage space on your machine.

While you can't be sure that the chains will contain the hash you need, the more chains you've generated (or are referencing) the more certain you can be. Unfortunately, each chain is time-intensive to generate, and increasing the number of chains increases the time you need.

How do you defend against these types of attacks?

First, a layered defense of all systems. If you can prevent compromise of your systems via other methods (so the attacker can't get a copy of your hashed passwords), the attacker won't be able to crack them.

You can also use salting, which adds a random value to the password before encrypting it. That means that the precomputed value you've found (which matches the hash) won't work. The encrypted text is not based solely on the unencrypted text. Because the salt is different for each password, each needs to be cracked individually.

Salting is now included in most major hash types as an option. While Windows doesn't currently use salting, they can encrypt stored hashes if you use the 'SYSKEY' tool.

You can also use 'rounds', or hashing a password multiple times. Using rounds (particularly if the number of rounds is randomly chosen for each user), makes the hacker's job harder. This is most effective when combined with salting.

Unfortunately, a hacker who has the hashed passwords will have also have access to the number of rounds used and the salt used (because in order to get that list they've probably compromised . The salt and number of rounds used is stored with the password hash, meaning that if the attacker has one, they also have the other. However, they won't be able to use precomputed rainbow tables available online, and will have to compute their own tables (which is extremely time consuming).

One other method designed to increase the difficulty of cracking the password is to use a pepper. Pepper is similar to salt, but while a salt is not secret (it's stored with the hashed password), pepper is stored separately (for example, in a configuration file) in order to prevent a hacker from accessing it. This means the pepper is secret, and its effectiveness depends on this.

Pepper needs to be different for each application it is used for, and should be long enough to be secure. At least 112 bits is recommended by the National Institute of Standards and Technology.

While using a pepper can be effective in some cases, there are some downsides. First, no current algorithm supports peppers, which means practically, this is impossible to implement at scale. That is, unless you're creating your own algorithms. Listen to Bruce Schneier. Don't do that.

For a longer article on the problems with peppers, check out this thread.

Finally, use strong (at least 12 character), complex passwords, and implement strong password policies across all systems. This can include forcing users to create strong passwords, testing their strength regularly, using password managers on an enterprise level, enforcing use of 2FA, and so on.

Confused about what makes a strong password?

https://xkcd.com/936/

It seems really easy to get hacked. Should I be concerned?

The most important thing to remember about hacking is that no one wants to do more work than they have to do. For example, calculating rainbow tables is a lot of work. If there's an easier way to get your password, that's probably what a nefarious actor will try first (like phishing!).

That means that enabling basic cyber security best practices is probably the easiest way to prevent getting hacked. In fact, Microsoft recently reported that just enabling 2FA will end up blocking 99.9% of automated attacks.

https://xkcd.com/538/

Happy hacking!

Additional Reading:

More details on hash chains

Another explanation of rainbow tables

A list of rainbow tables online

Unstable times are insecure times, and we’ve already got enough going on to deal with. When humans are busy and under stress, we tend to get lax in less-obviously-pressing areas, like the security of our online accounts.

These areas only become an obvious problem when it’s too late for prevention. Thankfully, most of the work necessary to keep up our cybersecurity measures can be outsourced.

Implementing proper cybersecurity measures can be fiddly, and I especially dislike fiddling with things that I could avoid fiddling with.

These fiddly things include resetting forgotten passwords, transferring multifactor authentication (MFA) codes when I change devices, and dealing with the fallout of compromised payment details in the event one of my accounts is still breached.

Here are three changes I’ve made that significantly reduce the chances of needing to fiddle with any of these things again. You can too.

1Password

I’ve historically avoided password managers because of an irrational knee-jerk reaction to putting all my eggs in one basket.

You know what’s great for irrational reactions? Education. To figure out if putting all my passwords into a password manager is more secure than not using one, I set out to see what some smart people wrote about it.

First, we need to know a thing or two about passwords. Troy Hunt figured out almost a decade ago that trying to remember strong passwords doesn’t work. In more recent times, Alex Weinert expanded on this in Your Pa$$word doesn’t matter.

TL;DR: our brains aren’t better at passwords than computers, and please use MFA.

So passwords don’t matter, but complicated passwords are still better than memorable and guessable ones.

Since I’ve next to no hope of remembering a dozen variations of p/q2-q4! (I’m not a chess player), this is a task I can outsource to 1Password. I’ll still need to remember one, long, complicated master password - 1Password uses this to encrypt my data, so I really can’t lose it - but I can handle just one.

Using 1Password specifically has another, decidedly obvious, advantage. I chose 1Password because of their Watchtower feature. Thanks to Troy Hunt’s Have I Been Pwned, Watchtower will alert you if any of your passwords show up in a breach so you can change them. Passwords still don’t completely work, but this is probably the best band-aid there is.

One last bonus is that using a password manager is a heck of a lot more convenient. Complicated passwords need not take two tries to type.

When it comes to sites that I only rarely use, and don’t consider important, I’m typically far more likely to end up (re)setting those passwords to something memorable, and thus something easily hacked. Even - perhaps especially - unimportant sites can open doors to your more important ones.

Using 1Password and generated passwords, those sites are now also first-class citizens in the land of strong passwords, instead of being half-abandoned and half-open attack vectors.

So, yes, all my eggs are in one basket. A well-protected, complex, and monitored basket, as opposed to being scattered about in several of those paper cartons from the grocery store that don’t really close and certainly can’t survive a rather gentle bump as you come in the doorway, Victoria, how many times do I need to remind you to be careful.

Authy

Okay - so it’s more like one-and-a-half baskets. ??

Authy, from the folks over at Twilio, provides a 2FA solution that’s more secure than SMS (I find this to be an interesting intersection, coming from Twilio, and I applaud.) Unlike Google Authenticator, you can choose to back up your 2FA codes in case you lose or change your phone. (1Password offers 2FA functionality as well - but, you know, redundancies.)

With Authy, your back up is encrypted with your password, similarly to how 1Password works. This makes it the second password you can’t forget, if you don’t want to lose access to your codes. If you reset your account, they all go away. I can deal with remembering two passwords; I’ll take that trade.

I’ve tried other methods of MFA, including hardware keys, which can make accessing accounts on your phone more complicated than I care to put up with. I find the combination of 1Password and Authy to be the most practical combination of convenience and security that yet exists in my knowledge.

Privacy.com

Finally, there’s one last line of defense you can put in place in the unfortunate event that one of your accounts is still compromised. All the strong passwords and MFA in the world won’t help if you open the doors yourself, and scams and phishing are a thing.

Since it’s rather impractical to use a different real credit card every place you shop, virtual cards are just a great idea. There’s no good reason to spend an afternoon (or more) resetting your payment information on every account just to thwart a misbehaving merchant or patch up a data breach from that online shop for cute salt shakers you made a purchase at last year (just me?).

By setting up a separate virtual card for each merchant, in the event that one of those merchants is compromised, I can simply pause or delete that card. None of my other accounts or actual bank details are caught up in the process. Cards can have time-oriented limits or be one-off burner numbers, making them ideal for setting up subscriptions.

This is the sort of basic functionality that I hope, one day, becomes more prevalent from banks and credit cards. In the meantime, I’ll keep using Privacy.com. That’s my referral link; if you’d like to thank me by using it, we’ll both get five bucks as a bonus.

Outsource better security

All together, implementing these changes will probably take up an afternoon, depending on how many accounts you have. It’s worth it for the time you’d otherwise spend resetting passwords, setting up new devices, or (knock on wood) recovering from compromised banking details.

Best of all, you’ll have continual protection just running in the background - an effortless boost to your personal cybersecurity posture.

We have the technology. Free up some brain cycles to focus on other things - or simply remove some unnecessary stress from your life by outsourcing the fiddly bits.

A brief note - this article is about the theory of how to crack passwords. Understanding how cybercriminals execute attacks is extremely important for understanding how to secure systems against those types of attacks.

Attempting to hack a system you do not own is likely illegal in your jurisdiction (plus hacking your own systems may [and often does] violate any warranty for that product).

Let's start with the basics. What is a brute force attack?

This type of attack involves repeatedly trying to login as a user by trying every possible letter, number, and character combination (using automated tools).

This can be done either online (so in real-time, by continually trying different username/password combinations on accounts like social media or banking sites) or offline (for example if you've obtained a set of hashed passwords and are trying to crack them offline).

Offline isn't always possible (it can be difficult to obtain a set of hashed passwords), but it is much less noisy. This is because a security team will probably notice many, many failed login accounts from the same account, but if you can crack the password offline, you won't have a record of failed login attempts.

This is relatively easy with a short password. It becomes exponentially more difficult with a longer password because of the sheer number of possibilities.

For example, if you know that someone is using a 5 character long password, composed only of lowercase letters, the total number of possible passwords is 26^5 (26 possible letters to choose from for the first letter, 26 possible choices for the second letter, etc.), or 11,881,376 possible combinations.

But if someone is using an 11 character password, only of lowercase letters, the total number of possible passwords is 26 ^11, or 3,670,344,486,987,776 possible passwords.

When you add in uppercase letters, special characters, and numbers, this gets even more difficult and time consuming to crack. The more possible passwords there are, the harder it is for someone to successfully login with a brute force attack.

How to protect yourself

This type of attack can be defended against in a couple of different ways. First, you can use sufficiently long, complex passwords (at least 15 characters). You can also use unique passwords for each account (use a password manager!) to reduce the danger from data breaches.

A security team can lock out an account after a certain number of failed login attempts. They can also force a secondary method of verification like Captcha, or use 2 factor authentication (2FA) which requires a second code (SMS or email, app-based, or hardware key based).

Here's an article on how to execute a brute force attack.

How can you crack passwords faster?

A dictionary attack involves trying to repeatedly login by trying a number of combinations included in a precompiled 'dictionary', or list of combinations.

This is usually faster than a brute force attack because the combinations of letters and numbers have already been computed, saving you time and computing power.

But if the password is sufficiently complex (for example 1098324ukjbfnsdfsnej) and doesn't appear in the 'dictionary' (the precompiled list of combinations you're working from), the attack won't work.

It is frequently successful because, often when people choose passwords, they choose common words or variations on those words (for example, 'password' or 'p@SSword').

A hacker might also use this type of attack when they know or guess a part of the password (for example, a dog's name, children's birthdays, or an anniversary - information a hacker can find on social media pages or other open source resources).

Similar protection measures to those described above against brute force attacks can prevent these types of attacks from being successful.

What if you already have a list of hashed passwords?

Passwords are stored in the /etc/shadow file for Linux and C:\Windows\System32\config file for Windows (which are not available while the operating system is booted up).

If you've managed to get this file, or if you've obtained a password hash in a different way such as sniffing traffic on the network, you can try 'offline' password cracking.

Whereas the attacks above require trying repeatedly to login, if you have a list of hashed passwords, you can try cracking them on your machine, without setting off alerts generated by repeated failed login attempts. Then you only try logging in once, after you've successfully cracked the password (and therefore there's no failed login attempt).

You can use brute force attacks or dictionary attacks against the hash files, and may be successful depending on how strong the hash is.

Wait a minute - what's hashing?

35D4FFEF6EF231D998C6046764BB935D

Recognize this message? It says 'Hi my name is megan'

7DBDA24A2D10DAF98F23B95CFAF1D3AB

This one is the first paragraph of this article. Yes, it looks like nonsense, but it's actually a 'hash'.

A hash function allows a computer to input a string (some combination of letters, numbers, and symbols), take that string, mix it up, and output a fixed length string. That's why both strings above are of the same length, even though the strings' inputs were very different lengths.

Hashes can be created from nearly any digital content. Basically all digital content can be reduced to binary, or a series of 0s and 1s. Therefore, all digital content (images, documents, etc.) can be hashed.

There are many different hashing functions, some of which are more secure than others. The hashes above were generated with MD5 (MD stands for "Message Digest"). Different functions also differ in the length of hash they produce.

The same content in the same hash function will always produce the same hash. However, even a small change will alter the hash entirely. For example,

2FF5E24F6735B7564CAE7020B41C80F1

Is the hash for 'Hi my name is Megan' Just capitalizing the M in Megan completely changed the hash from above.

Hashes are also one-way functions (meaning they can't be reversed). This means that hashes (unique and one-way) can be used as a type of digital fingerprint for content.

What's an example of how hashes are used?

Hashes can be used as verification that a message hasn't been changed.

When you send an email, for example, you can hash the entire email and send the hash as well. Then the recipient can run the received message through the same hash function to check if the message has been tampered with in transit. If the two hashes match, the message hasn’t been altered. If they don’t match, the message has been changed.

Also, passwords are usually hashed when they're stored. When a user enters their password, the computer computes the hash value and compares it to the stored hash value. This way the computer doesn’t store passwords in plaintext (so some nosy hacker can't steal them!).

If someone is able to steal the password file, the data is useless because the function can’t be reversed (though there are ways, like rainbow tables, to figure out what plaintext creates the known hash).

What's the problem with hashes?

If a hash can take data of any length or content, there are unlimited possibilities for data which can be hashed.

Since a hash converts this text into a fixed length content (for example, 32 characters), there are a finite number of combinations for a hash. It is a very very large number of possibilities, but not an infinite one.

Eventually two different sets of data will yield the same hash value. This is called a collision.

If you have one hash and you're trying to go through every single possible plaintext value to find the plaintext which matches your hash, it will be a very long, very difficult process.

However, what if you don't care which two hashes collide?

This is called the 'birthday problem' in mathematics. In a class of 23 students, the likelihood of someone having a birthday on a specific day is around 7%, but the probability that any two people share the same birthday is around 50%.

The same type of analysis can be applied to hash functions in order to find any two hashes which match (instead of a specific hash which matches the other).

To avoid this, you can use longer hash functions such as SHA3, where the possibility of collisions is lower.

You can try generating your own hash functions for SHA3 here and MD5 here.

You can try to brute force hashes, but it takes a very long time. The faster way to do that, is to use pre-computed rainbow tables (which are similar to dictionary attacks).

It seems really easy to get hacked. Should I be concerned?

The most important thing to remember about hacking is that no one wants to do more work than they have to do. For example, brute forcing hashes can be extremely time consuming and difficult. If there's an easier way to get your password, that's probably what a nefarious actor will try first.

That means that enabling basic cyber security best practices is probably the easiest way to prevent getting hacked. In fact, Microsoft recently reported that just enabling 2FA will end up blocking 99.9% of automated attacks.

https://xkcd.com/538/

Additional Reading:

Popular password cracking tools

Have you ever received a 'sextortion' email telling you that your computer has been hacked and warning you that if you don't pay up, they will release videos of an intimate nature to your entire contact list? Did the email include an old password of yours as 'proof' that their claims were true? Did you wonder how they got your password?

What is Phishing?

Statistically, this was probably from a phishing email. In 2018, 93% of all breaches globally began with a phishing or pretexting attack.

Phishing emails are extremely common and highly effective. They use emotion such as fear and shame (in sextortion emails or 'male enhancement ads'), urgency (my boss needs this now!), or greed (I won a new car??).

They can also be sent via text message (SMiShing), voice (vishing), email (phishing), and social media phishing.

The more people adapt, the more the hackers change in response – their tactics are constantly evolving.

Usually phishing emails contain a link or an attachment. Once you click the link or open the attachment, they may install malware on your device or trick you into entering your credentials into a fake site (which looks just like the real site). The malware will check to see if it can exploit unpatched vulnerabilities in order to install more malware onto your system (which can then steal passwords, install keyloggers to record all of your keystrokes – and therefore your passwords! – and so on).

Once the hacker has stolen your credentials, they can do things like exfiltrate your personal financial data or account information, or those of your customers if this happens on your corporation's device.

Phishing deserves its own article entirely, so if you're interested in learning how to phish, check out this article.

How can you stop phishing from impacting you?

Defending against phishing is also difficult. As an individual, the best thing you can do is use caution when opening emails – be wary of emails which play on your emotions, ask you to make quick decisions, or seem too good to be true.

Look out for unusual senders (do you recognize the person emailing you? Is this the same email address they've used before?), or unexpected links or attachments. If you're unsure if an email is legitimate, confirm that it is with the sender via a different method of communication.

You should also use antivirus and endpoint protection software. The paid version is better than the free version, as it is updated as new malware is identified. But the free version is usually better than nothing. I like Malwarebytes for laptops.

Security teams will use a myriad of tools:

• email filtering mechanisms that attempt to reduce the phishing and spam emails which reach user's inboxes,
• measures like SPF, DKIM, and DMARC which can help provide authentication that an email is telling the truth about where it came from,
• user awareness training,
• and endpoint protection mechanisms.

Endpoint protection mechanisms can range from simple anti-virus to agents installed on every device. These will try to prevent known malware from running, identify unusual behavior, and prevent malicious processes from running by alerting a security operations team or forcing the program to quit.

This way, even if the email gets through the filters and the user doesn't notice anything wrong, the endpoint protection will keep the malware from actually doing damage to the machine.

How else could someone have gotten my password?

Often when a hacker breaches a company, they will sell the usernames and passwords they've obtained on the dark web.

Surface Web: What you can find on Google or other popular search engines. This is probably most of what you think of as the internet. Compared to the deep web, this is a very small portion of information which is ‘online’.

Deep Web: Information which is online, but isn’t indexed (searchable) by Google and other popular browsers. This is information such as that contained in government or university databases. Often this information is hidden behind a paywall or other restriction mechanism.

Dark Web: The dark web requires certain browsers, such as a ‘TOR browser’ to access. Some, though not all, of this content is illegal. This is often a place where criminals gather to talk on forums, sell illegal services and goods, and sometimes activists living under repressive regimes gather to communicate.

If you were re-using passwords and usernames between different websites (particularly since your email is probably used as your username for many websites), a hacker might already have your username and password.

https://xkcd.com/792/

The hacker will then perform something called 'credential stuffing'. Credential stuffing is when an attacker takes these usernames and passwords and plugs them into an automated 'account checker' which basically tries the username/password combination across many, many different sites across the internet, from social media logins to bank accounts. If the password works, the hacker now has access to the account and can drain an account, sell the data, etc.

For a better description, check out XKCD's comic below.

https://xkcd.com/2176/

How do you defend against credential stuffing?

Don't reuse your passwords. Use a password manager like 1Password or LastPass. KeePass is (in my opinion) less user friendly, but it's free!

Password managers can securely store your passwords and often have browser extensions and apps so they can autofill your passwords across many accounts. Plus, you only have to remember one master password this way. But your master password now grants access to all of your other passwords, so make sure it's very strong!

They can also help you autogenerate very strong passwords, and some even have vaults so you can store other sensitive information (bank account details, insurance information, etc.).

I personally use 1Password because I like the family account option – if anyone in your family ever gets locked out, someone else can reset their account password (but won't have access to your individual vault).

You can also set up free alerts with Have I Been Pwned. This site aggregates information from data breaches and provides consumers with the ability to use that information to protect themselves. You can navigate to the 'Notify Me' tab at the top and enter your email address.

After you confirm the email address you've entered (where it will provide your current exposure), the site will send you an email anytime your email is involved in a data breach. That is, any breach the site is alerted to – their coverage is very good, but no single source will contain every leaked data breach. This way, you can just change the impacted password, and won't have to worry about it impacting any of your other accounts.

If you're working on security for a large organization, enterprise password management software (the same companies listed above provide these services) is a great idea, as well as strong password policies (mandating that your employees use sufficiently strong passwords). Have I Been Pwned also has a service which allows the domain owner to monitor for breaches which involve any email on the domain (and it's free!).

How else do hackers get passwords?

There are a few other possibilities – shoulder surfing, or basically watching you type your password – though this is unlikely given that the person has to be physically watching you.

Then there's theft of passwords which have been written down, or just pictures of written down passwords which are visible in photos. Again, this is much less likely than any of the above options as it typically comes from a targeted attack (which is inherently less common than crimes of opportunity).

Avoiding these two is pretty simple – don't allow someone to watch you enter your password, and don't write down your password. Use a password manager instead! If you simply have to write it down, store it someplace that someone is unlikely to search through or find by accident. I'd suggest the bottom of a box of tampons. Much more secure than a sticky note on your monitor.

It seems really easy to get hacked. Should I be concerned?

The most important thing to remember about hacking is that no one wants to do more work than they have to do. For example, breaking into your house to steal your password notebook is a lot harder than sending phishing emails from the other side of the world. If there's an easier way to get your password, that's probably what a nefarious actor will try first.

That means that enabling basic cyber security best practices is probably the easiest way to prevent getting hacked. In fact, Microsoft recently reported that just enabling Two-Factor Authentication will end up blocking 99.9% of automated attacks.

So, enable 2FA, use a password manager to autogenerate long, complex, unique passwords for every account, and think before you click! Avoid clicking on sketchy or unexpected links and attachments, and stay vigilant.

https://xkcd.com/538/

###

##

I am very tired of seeing arbitrary password rules that are different for every web or mobile app. It's almost like these apps aren't following a standard and are just making up their own rules that aren't based on good security practices.

All too often I see password entry requirements like this:

Apparently, my password is 'unacceptable' for AT&T because it's more than 24 characters long...

12 characters is an arbitrary number! This website actually wants you to be less secure.

Who came up with the idea that you need to have short passwords with only certain types of symbols that are impossible for the average human to remember?

XKCD made an excellent point about this here:

More Secure Passwords

Decades ago, it was recommended that people use more complex passwords containing numbers and symbols to make them more secure. That is no longer the recommendation of security professionals – even the ones who used to recommend more complex passwords now say that practice is outdated.

Security testing shows that the best ways to make passwords more secure is to simply make them longer and use a unique one for every app or website. They don't even have to be fancy or completely random. But you should be using a password manager to generate them anyway.

I recommend using 1Password (browser), Encryptr (desktop), or RoboForm (browser). Then you will just have one password to remember and have the password manager do the hard work of generating a unique one for every app or website you use.

More Information

• Here is a full list of best practices for creating passwords by security researcher Troy Hunt.
• If you want to dive deep into password strength estimation, I highly recommend this talk by Daniel Wheeler at Dropbox.

Conclusion

Remember, make longer passwords, educate yourself by reading Troy Hunt's article, and use a password manager.

I hope you enjoyed this brief article. Let me know your feedback or additional recommendations in the comments.

Here is how you can reach me:

• gwenf@protonmail.com
• https://gwenfaraday.com
• Faraday Academy YouTube Channel

With Cybersecurity becoming a big concern, two-factor authentication (2FA) is a topic that is becoming hotter with each passing day.

After all, who doesn’t want to keep their private data safe? Two-factor authentication may not be a bulletproof solution but is one of the easiest and best ways to shore up your virtual security.

Treat 2-factor authentication as a supplement to strong passwords, not as a replacement.

Two-factor authentication adds another security layer to the login process, reducing the chances of your account getting hacked. Just knowing and entering your password is not enough since there is a second layer which is usually time sensitive. This makes the process a whole lot more secure.

Here are some facts you would want to know before you enable two-factor authentication:

Four out of five data breaches could be avoided by using 2FA

Cyber threats are on a rise and 2-factor authentication actually helps to counter them.

Majority of the hacking-related breaches take place due to weak or stolen passwords. Since many users tend to use the same password everywhere, the risk grows ten fold. Clearly, something more than just passwords are needed.

According to a Verizon’s Data Breach Report, 80% of data breaches could be eliminated by the use of two-factor authentication.

2FA makes sure that even if your password gets compromised, the hacker has to crack another security layer before they can access your account. And since most of the 2FA methods are time-dependent, it makes the hacker’s job so much more difficult.

No wonder all the major websites and banks provide an option to enable 2-factor security.

Two-factor authentication is not a replacement for strong passwords

Weak and repeated passwords are a bane to Cyber security. No matter which account or service you’re using, it’s always best to set a unique complex password.

Using repeated passwords all over the Internet makes us vulnerable to massive impacts even if one site’s security gets breached. In such a case, all our accounts can be at the attacker’s disposal.

Even if you enable two-factor authentication, strong passwords are a must. As mentioned earlier, treat 2FA as a supplement to strong passwords, not as a replacement.

Always use a complex combination of letters, numbers, and special symbols to generate a strong and unique password for each service you use. You can also use a service like LastPass to easily manage your passwords.

Facebook is one of the leading companies supporting two-factor authentication.

There are two ways you can get the passcodes

You can generate the passcodes for 2FA in multiple ways. Codes can be generated on the server and then sent to you via Email, SMS or phone call. This usually requires network connectivity for your mobile and thus can leave you prone to inaccessible accounts in remote areas.

The other option is to generate the passcode offline on your phone or a hardware device. You can easily generate 2FA passcodes on your phone via apps like Google Authenticator, Authy or TOTP Authenticator. There are also hardware devices like YubiKey available in the market for setting up two-factor authentication.

This method is more robust as no data connectivity is required, leaving you less prone to network phishing.

In some cases, the second step can also be biometric verification or entering a PIN you set by yourself earlier.

Always back up. You don’t want to be locked out of your account

2FA works on the premise that you always have access to the secondary passcode. But in case you use a 2-factor authentication app and you lose your phone or your data gets wiped out, you can be locked out of your account.

To avoid such a scenario, some websites provide backup codes which you must save securely and can use in such situations. Alternatively, you can use an authentication app which provides the option to back up your security key and related data.

We developed the TOTP Authentication app for iOS and Android keeping this in mind. The app allows you to back up your security key and related information either to your device or to online storage options such as Google Drive in a hassle free way. The encrypted backup file can be set up on another device with just a couple of taps. You can download the app from iTunes store from here, and from Google Play Store from here.

Conclusion

Two-factor authentication is slowly becoming a norm in the digital world. Most of the banks, cloud storage services and social media websites already provide the option. You should switch on 2FA wherever possible. As they say, prevention is better than cure.

Have any questions about 2FA authentication? Shoot them in the comments!

To know more about 2-factor authentication you can also check out this article.