So I have all my passwords, TOTP backup codes, and account recovery codes in my password manager (Bitwarden.) In turn, Bitwarden is secured with a master password and TOTP 2FA. I have a recovery code for the 2FA in the event that I can't get to andOTP anymore (2FA app.) The thing is, where do I put that code? I can't put it in a note app or anything, because if I'm locked out of Bitwarden, I don't have my passwords. Do you see my problem? I was thinking about physically writing it down, but that makes me nervous because I might lose it. Are there any good solutions to this problem?

Preface

Software security is one of those subjects that often gets overlooked, both in academia and in professional projects, unless you're specifically working with some existing security-related element (e.g. you're taking a course on security basics, or updating your password hashing algorithm). As a result, we frequently see stories of rather catastrophic data leaks from otherwise reputable businesses, leaks which should have been entirely preventable with even the most basic of safeguards in place.

With that in mind, I thought I would switch things up and discuss something security-related this time.

Background

It's commonplace for complex software systems to avoid unnecessarily large expenses, especially in terms of technical debt and the capital involved in the initial development costs of building entire systems for e.g. geolocation or financial transactions. Instead of reinventing the wheel and effectively building a parallel business, we instead integrate with existing third-party systems, typically by using an API.

The problem, however, is that sometimes these third-party systems process requests over a long period of time, potentially on the order of minutes, hours, days, or even longer. If, for example, you have users who want to purchase something using your online platform, then it's not a particularly good idea to having potentially thousands of open connections to that third-party system all sitting there waiting multiple business days for funds to clear. That would just be stupid. So, how do we handle this in a way that isn't incredibly stupid?

There are two commonly accepted methods to avoid having to wait around:

1. We can periodically contact the third-party system and ask for the current status of a request, or
2. We can give the third-party system a way to contact us and let us know when they're finished with a request.

Both of these methods work, but obviously there will be a potentially significant delay in #1 between when a request finishes and when we know that it has finished (with a maximum delay of the wait time between status updates), whereas in #2 that delay is practically non-existent. Using #1 is also incredibly inefficient due to the number of wasted status update requests, whereas #2 allows us to avoid that kind of waste. Clearly #2 seems like the ideal option.

Method #2 is what we call a webhook.

May I see your ID?

The problem with webhooks is that when you're implementing one, it's far too easy to forget that you need to restrict access to it. After all, that third-party system isn't a user, right? They're not a human. They can't just give us a username and password like we want them to. They don't understand the specific requirements for our individual, custom-designed system.

But what happens if some malicious actor figures out what the webhook endpoint is? Let's say that all we do is log webhook requests somewhere in a non-capped file or database table/collection. Barring all other possible attack vectors, we suddenly find ourselves susceptible to that malicious actor sending us thousands, possibly millions of fraudulent data payloads in a small amount of time thanks to a botnet, and now our server's I/O utilization is spiking and the entire system is grinding to a halt--we're experiencing a DDoS!

We don't want just anyone to be able to talk to our webhook. We want to make sure that anyone who does is verified and trusted. But since we can't require a username and password, since we can't guarantee that the third-party system will even know how to make use of them, what can we do?

The answer is to use some form of token-based authentication--we generate a unique token, kind of like an ID card, and we attach it to our webhook endpoint (e.g. https://example.com/my_webhook/{unique_token}). We can then check that token for validity every time someone touches our webhook, ensuring that only someone we trust can get in.

Class is in Session

Just as there are two commonly accepted models for how to handle receiving updates from third-party systems, there are also two common models for how to assign a webhook to those systems:

1. Hard-coding the webhook in your account settings, or
2. Passing a webhook as part of request payload.

Model #1 is, in my experience, the most common of the two. In this model, our authentication token is typically directly linked to some user or user-like object in our system. This token is intended to be persisted and reused indefinitely, only scrapped in the event of a breach or a termination of integration with the service that uses it. Unfortunately, if the token is present within the URL, it's possible for your token to be viewed in plaintext in your logs.

In model #2, it's perfectly feasible to mirror the behavior of model #1 by simply passing the same webhook endpoint with the same token in every new request; however, there is a far better solution. We can, instead, generate a brand new token for each new request to the third-party system, and each new token can be associated with the request itself on our own system. Rather than only validating the token itself, we then validate that the token and the request it's supposed to be associated with are both valid. This ensures that even in the event of a breach, a leaked authentication token's extent of damage is limited only to the domain of the request it's associated with! In addition, we can automatically expire these tokens after receiving a certain number of requests, ensuring that a DDoS using a single valid token and request payload isn't possible. As with model #1, however, we still run into problems of token exposure if the token is present in the URL.

Model #2 treats each individual authentication token not as a session for an entire third-party system, but as a session for a single request on that system. These per-request session tokens require greater effort to implement, but are inherently safer due to the increased granularity of our authentication and our flexibility in allowing ourselves to expire the tokens at will.

Final Thoughts

Security is hard. Even with per-request session tokens, webhooks still aren't as secure as we might like them to be. Some systems allow us to define tokens that will be inserted into the request payload, but more often than not you'll find that only a webhook URL is possible to specify. Ideally we would stuff those tokens right into the POST request payload for all of our third-party systems so they would never be so easily exposed in plaintext in log files, but legacy systems tend to be slow to catch up and newer systems often don't have developers with the security background to consider it.

Still, as far as securing webhooks goes, having some sort of cryptographically secure authentication token is far better than leaving the door wide open for any script kiddie having a bad day to waltz right in and set the whole place on fire. If you're integrating with any third-party system, your job isn't to make it impossible for them to get their hands on a key, but to make it really difficult and to make sure you don't leave any gasoline lying around in case they do.

Like millions of people, I have a router at home, with WiFi and admin passwords set up.

If an attacker request comes in, there are no port forwarding rules set, and the router should say "hey request from the internet, I don't know to which device you want to go, sorry I'll drop you then", and I'm secure. But I don't think it's that simple. If a packet from the outer network can attack my LAN without using port forwarding, how?

Which router settings should I be really looking for to make home LAN more secure? Or what are the keywords of network security to start with?

This is a sort of continuation of a previous topic I posted. This weekend I will be wiping and reinstalling my computer and encrypting all of my drives in the process. In doing so, I will have to choose secure passphrases. As such, I have some questions about how best to do this:

1. I have three drives that will be encrypted. Is it okay to have the same passphrase for all of them, or should I have different ones for each?

2. In looking up info on this topic, I came across this article which recommends something called a Diceware wordlist. The premise is that you roll dice which match to a list of 7000+ words. You then string six or more of these words together which become your passphrase. Is this a sound way to generate one?

3. Rather than using the Diceware wordlist, couldn't I roll my own password of the same type using six "random" words of my choosing? I feel like that would be easier to remember, but am I weakening security in doing so?

4. If the Diceware method is to be trusted, does that mean I do not need to pepper my passphrase with digits, mixed case, and special characters? Or should I add these anyway?

5. I'm also considering changing over passwords on a lot of my online accounts based on this method. I like the idea of using a single passphrase as a root, but how do you modify it so that it is different for each account? Would I do something like [dicewarewords]tildes, [dicewarewords]spotify, [dicewarewords]ubuntuforums, etc.? I feel like it would be too on-the-nose, and it would make it easy to guess my other passwords if one were compromised. On the other hand, I don't like the idea of using a password manager to generate a random string for me. I'd like to still be able to login even without my password manager.

6. For people that have used something like this, how do you then deal with password restrictions on sites? I know that no matter how great I set things up I'm still going to have to make exceptions for sites that that either require or forbid numbers, mixed case, or special characters, have character limits, or make me change my password frequently.