Skip to content

Personal key rotation 2: security and availability

Posted on:August 18, 2024 at 09:00 PM

In this post, I discuss how to achieve a good balance between security and availability for my online accounts. I illustrate these concepts using excerpts from my asset graph. This is part two in a four-part series on personal key rotations, or, how to gain control over my online life. Part one introduced the asset graph, a visual way to list the various accounts, passwords, and dependencies that together form my online life.

In a nutshell, security measures how well my stuff is protected, or how difficult it is for an attacker to gain access. For example, an account that is protected with just a short password has weak security. An attacker could either send me a phishing message to trick me into revealing my password, or guess it if it’s too simple. That would be enough to gain access. On the other hand, an account protected by a passkey (a fingerprint-unlocked key stored on my phone) has stronger protection. An attacker would both need my phone, and force me to unlock it, to get in.

The other part of the balance is availability. It measures how easily and reliably I can access my stuff, or how difficult it is to lock myself out. For example, a complex backup setup with encrypted files stored on a disk has low availability: if the disk breaks, or I forget my password, then my backup is gone. Conversely, an account to which I’m logged in on both my phone and my laptop, with a recovery email address, has high availability. I’m unlikely to lose it even if one of the access methods fails.

Examples from my asset graph

An single password protects many accounts

Here is an example of an insecure setup: My Google account is protected by a simple password. This by itself is not that problematic. However, the asset graph reveals how other accounts depend on this Google account: Sites like Reddit or Amazon can send password recovery emails to my Gmail. Someone with access to my Google account can visit Reddit, click on “I forgot my password”, and use the reset link in the email to gain control of the Reddit account. For other sites like OpenAI, I can directly use Google’s single-sign-on to log in (also known as “login with Google”).

The solution, in this case, is to better protect my Google account. I should enable two-factor authentication1.

In the asset graph, this adds an extra AND node between the password and the Google account. AND nodes are my friends when it comes to security. To check whether my online stuff is sufficiently secure, I look at high-value items in the asset graph, and check whether each of them has an AND node that joins two different authentication factors.

The password store is a single point of failure

The second example shows a setup with stronger security. It features a well-protected password store to manage passwords. In addition, the high-value accounts have two-factor authentication enabled. The problem with this setup is not its security; it is the availability.

In this example, the password store is a single point of failure. All paths go through it. If something goes wrong (for example, if I spill coffee over my laptop, or I forget my master password), I lose access to everything. This is still the case even if I have backups, or if I store a copy of the passwords on Google Drive. The asset graph shows that these backups would not help, because I cannot read them without my password store.

The solution here is to add alternative access paths. For example, I might memorize the Google password if I use it often enough, or I could write it down on paper. In the asset graph, having multiple alternative paths to an asset is a sign of high availability. Note, however, that each asset is only as secure as the weakest path that leads to it.

An insecure setup where a recovery code is stored next to a password

In the third example, we see a failed attempt at balancing security and availability. My GitHub account has two-factor authentication enabled. GitHub knows that there is a risk of locking myself out if I lose access to my second factor. To mitigate this, GitHub provides me with single-use recovery codes. Their documentation explains how these work:

GitHub's documentation for two-factor recovery codes

In this example, I carelessly stored my recovery codes next to my password, in the password store. This collapses two authentication factors into one. Someone with access to my password store can now bypass my two-factor authentication.

The example illustrates the concept of a root of the asset graph. I define a root as a secret that has to be stored independently, instead of being reachable from some other node. To be a true second factor, a recovery code needs to be stored separately from my password; it could be a root by itself (e.g., if I store it written on a piece of paper), or part of a chain that has a separate set of roots than those that lead to the password store.

Roots are particularly important secrets. They are the things that are needed to bootstrap my entire online life. Unlike other secrets, I cannot simply store them in my password store. Thus, I want to keep the number low, lest I forget a PIN or passphrase. But I also want to keep multiple authentication factors separate from each other.

The security/availability trade-off

From the examples, it has become clear that security and availability form a trade-off. Increasing one typically decreases the other. The examples showed ways to increase security and availability, and also illustrated how things can go wrong.

I keep three main take-aways from this post:

In the next part of the series, I will look at practical ways to do this. I will give concrete recommendations for tools that I find valuable to manage my accounts, passwords, etc. Please come back on August 25 for part 3!

I’d love to hear feedback. How did you find the series so far? What would you like to know? Feel free to drop me an anonymous comment at https://www.admonymous.co/jonaswagner.

Footnotes

  1. For high-value accounts, Google also offers an advanced protection program. It enforces stricter rules on two-factor authentication. For example, users with advanced protection need phishing-resistant security keys.