Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

You are reading the security handbook of the Stacks ecosystem.

Target audience: everyone

The world out there is scary and adversarial. Regardless of what you do at Stacks, you MUST read this handbook and apply its best practices to keep you (and the ecosystem) safe. Where appropriate, you will also find more specific pointers (e.g., if you are a developer, a trader, etc.).

How to use this handbook

Security always involves trade-offs (e.g., against usability). We need our ecosystem to be safe, but we also need to get work done. This handbook tries to make all this as easy as possible for you, by:

  1. Clearly calling out what is non-negotiable from a security standpoint (MUSTs).

  2. Making it as easy as possible for you, the reader, to follow what is required...

  3. ...while ensuring you understand why requirements are there and what threat model they protect from.

In practice, this means that this handbook will tell both the requirements and how to implement them, so you do not need to reinvent the wheel or venture on a number of side-quests.

Where possible, a secure setup should be the default (e.g., when using a pre-configured laptop).

You SHOULD NOT deviate from what is recommended unless you have an excellent reason to do that. If you think that's the case, check with your line manager.

Must read

First read the introduction. This will let you know what to expect from the handbook, and how to use the information contained therein.

Next read our description of the threat model we are protecting against.

Then go on to read the high level set of instructions to follow.

Once you've done this, feel free to browse the rest of the handbook, especially any pages which relate to your specific role within the organization.

Threat Model

Security is never absolute, instead always relative to a set of threats. This page describes the threat model for this handbook.

A remote attacker going for monies 💰

99% of the time, attackers will go after crypto (tokens, stablecoins, you name it). 99% of those times, the attack will play by the following book:

  1. Spear phishing: Email, Telegram messages, fake meeting invitations. Anything to get you to download and execute a malicious file/application (technically, a "payload").
  2. Local device compromise: The malicious file/applications gives an attacker (full) control of your machine. They will leverage it to grab any secret you have access to and to spread further (e.g., to other members of your organization).
  3. Grab and run: The attacker will enumerate all secrets on your system (usernames, passwords, seeds to wallets, cryptographic keys, etc.) and steal them. Then (sometimes a few weeks after) they will use those secrets to steal crypto funds and/or impersonate you, so they can spread the attack further.
  4. Lateral movements: Impersonating you (e.g., on Telegram) allows the attacker to reach out to your social network (e.g., BD partners, fellow developers, etc.) and spear phishing them. So the cycle begins again.

This handbook will mostly focus on the threat model we just described, since they account for 99% of the crypto heist we have collectively seen so far as an industry.

In a few cases, the threat model will also expand to include additional threats (e.g., evil maids). When that happens, you will find it properly highlighted.

The remaining 1%

It is easy to think about additional threats, e.g. sophisticated attackers that have deep pockets and are willing to spend millions of dollars to circumvent the defenses we (as an ecosystem and as an industry) put up.

Those threats do exist, but they are order of magnitudes less frequent than all the others. An attacker will not spend a few million dollars 0-day to remotely compromise you if they can just get you to click on a link and install their malware.

For these reasons, this handbook will focus on the 99% threats that are prevalent, while giving advanced readers pointers on how to (try to) mitigate the remaining 1%.

If you believe you are being targeted by an attacker outside the threat model depicted above, reach out!

At a high level

The attacker we are modeling for will only manage to steal secrets they can access from your machine. They can't steal what is not there or can't be reached from it.

The majority of the requirements and recommendations in this handbook will diligently work in that direction: By ensuring your machine holds as few secrets as possible (ideally none!). Then, multi-factor authentication through external wallet keys will do the rest.

What does this mean in practice?

No cryptographic keys

You MUST NOT, under any circumstances, store cryptographic keys or wallet seeds where an attacker can read them from your machine. You MUST NOT store them in a password manager, as files, images, etc. Instead, use hardware wallets.

Why?: An attacker compromising your device will not be able to steal cryptographic keys from it if they are not there.

2FA: Always and on hardware devices

You MUST enable two-factor authentication on any and all your accounts. The second factor MUST be a hardware device (e.g., your smartphone, or a security key).

Your organization will implement Single sign-on on as many services as possible. This way, you will only need to handle one account (e.g., for Google Workspace).

Why?: An attacker who compromised your device might be able to get your passwords, but they won't be sufficient without second factor (which will NOT be on your device, but on separate hardware).

Separate devices for work

You MUST use a separate device exclusively for work.

Why?: So that an attacker cannot compromise your personal accounts if they manage to compromise your work device.

Hardware security keys

Hardware security keys allow you to securely keep second factors and cryptographic keys physically separated from your work device (e.g., your laptop). In addition, these keys will not unlock their secrets unless you touch them, proving you are physically present.

All this ensures that a remote attacker who controls your machine cannot use your security key. We will use hardware security keys for multi-factor authentication.

Which key should you get?

We recommend getting at least two Yubikey 5C, providing connectivity through USB-C (so you can plug it into your laptop and most phones) and NFC.

You MUST keep one of them on you at all times and leave the other in a safe place (so that if you lose one, you have a backup).

We will be using these keys for:

  • WebAuthn (everyone, used for passkeys)
  • OATH - TOTP (everyone, used for TOTPs)
  • FIDO2 (if you are a developer, used for SSH)
  • SmartCard / PIV (if you are a developer, used for SSH when FIDO2 is not an option)

Configuration

To configure your Yubikey(s), install the Yubico Authenticator. In case you need them, here are its full docs.

Verify your Yubikey

Verify that your Yubikey is genuine at this website.

Disable Yubico OTP

We will not be using Yubico OTP, so you can disable it (if the authenticator proposes it after you have plugged in the Yubikey).

Set a FIDO PIN

You MUST set a FIDO PIN on your Yubikey(s). This ensures that if it gets lost or stolen, an attacker cannot use it without also knowing the PIN.

Go to the app Configuration, then navigate to "FIDO/Manage PIN". Follow the instructions to set a 4-digits PIN. Or use ykman from the command line:

ykman fido access change-pin
Enter your new PIN:
Repeat for confirmation:
FIDO PIN updated.

If you are on iOS, you will need to use NFC instead of USB-C. Put your Yubikey on a table, touch it with the top of your iPhone. It will prompt you to open the authenticator.

Set an OATH password

You MUST set a OATH password so that, similarly as we did for the FIDO PIN, a lost Yubikey can't be used without it.

Read here for instructions.

When asked by the application, you can protect your password with FaceID (or similar) to improve UX.

Using your hardware security key

Continue to use your hardware security key for:

  1. Multi-factor authentication
  2. SSH

Multi-factor authentication

Multi-factor authentication ensures that if your username/passwords are ever compromised, an attacker will not be able to authenticate as you, missing something else – typically, "something you have".

Here are the "multiple factors" we will be using:

  1. Username
  2. Password: "something you know"
  3. Hardware security key: "something you have"

You MUST enable multi-factor authentication for all your accounts on all services. For this to be effective, you MUST keep factors separate from each other. This means that you MUST NOT store your second factor in your password manager. Instead, use hardware security keys.

Which second factor

Passkeys

The modern and most secure way to add a second factor to your account is through passkeys. They provide good UX and are resistant to phishing.

If a service allows you to use passkeys as a second factor, you MUST prefer it to any other method. Setting things up depend on each service, for instance:

  1. Google
  2. GitHub

When authenticating to a service, you will be asked for a username and password, then prompted to insert your security key, insert its FIDO PIN, and then touch it to confirm your presence.

Some services will also allow "passwordless" login, where the security key is enough to authenticate.

Time-based one-time password

If a service does not support passkeys (yet), they will use TOTPs as an alternative.

Please see here for how to setup TOTPs for your Yubikeys.

When authenticating to a service, you will be asked for your TOTP for that account. Use the Yubico Authenticator to get it (instructions here).

What about recovery codes?

When setting up multi-factor authentication, some services will prompt you to store some recovery codes to use in case you lose your hardware security key. While it might be tempting to go on and store them in your password manager, you MUST NOT do that, as it would defeat the purpose of the second factor.

Instead, either:

  1. register multiple hardware second factors (so that you cannot lock yourself out) and destroy the recovery codes;
  2. print out the recovery codes as store them in a safe.

What about my phone number?

SMS-based two-factor authentication is insecure and MUST NOT be used; instead, rely on hardware devices. SIMs can be unfortunately swapped. When that happens, the attacker will control second factor.

If you need to use a service that will only allow phone number 2FA, reach out!

Cryptographic wallets

A wallet holds a set of private keys (very large, random numbers) that can be used to spend coins. All these keys are generated from a seed phrase. The seed phrase is the key to the kingdom! You MUST NEVER store the seed phrase anywhere accessible via a device (be it a file, a digital note, a picture, or even an entry in a password manager). Similarly, you MUST NEVER share it with another user.

Ground rules

  1. You MUST NEVER store seed phrases digitally
  2. You MUST NEVER share seed phrases with other users
  3. You MUST NEVER use wallet browser extensions

Warm wallets: <$1K

If you are storing less than $1K, you MAY use a software wallet on your smartphone since it is more convenient to use than a hardware wallet. You MUST NOT use a browser extension on your laptop, because it is easier for an attacker to compromise it. You SHOULD hand-write the seed phrase generated by the mobile wallet and store it in a safe place. You MUST NOT store it digitally.

Cold wallets: <$1M

If you are storing up to $1M, you MUST use a hardware wallet, such as a Ledger device. These keep the private key encrypted inside the device, and are resistent to tampering. Teams MUST have a set of N >= 3 devices, with transaction outputs spendable by any of the devices (1 of N multisig), so hardware failures do not result in losing funds. For N < 5, at least one team member MUST keep a backup device or seed phrase in a safe deposit box. For N >= 5, the risk of leaking the backup device or seed phrase is greater than the risk all devices failing, so backups MUST NOT be made.

If you need to store more than $1M, you MUST contact us for specific instructions.

Clear signing

You MUST ALWAYS verify, to the extent possible, the destination address(es) of any transaction you send. Many recent attacks, from ByBit to the latest NPM poisonings, have surreptitiously replaced user specified data with attacker data, resulting in stolen funds. In some cases the true data displayed after alteration, in others not.

To combat this, Ledger devices support clear signing. This uses the hardware screen of a Ledger device to display a human readable description of the transaction before you agree to sign. While the frontend app that interacts with your Ledger device may more easily be compromised, the hardware screen is much more resistent to such attacks.

When you verify an output address such as a smart contract (SC), you MUST verify the address from an external source, such as previously downloaded documentation. SC calls though involve not just addresses, but also functions and parameters; verify that the entire SC call is what you have intended. User wallet addresses MUST also be verified; when possible, this should include a voice call with the user in question where the address is read and the voice is recognized.

So for software wallets, you MUST ALWAYS confirm the details before agreeing to sign. This will NOT stop all attacks, which is why you SHOULD ALWAYS consider using hardware wallets even when not required to do so. For hardware wallets, you MUST ALWAYS confirm the details on the hardware screen.

Hardware wallets

Below we will include specific instructions for configuring various hardware wallets.

Ledger Nano X

Instructions for setting up a Ledger Nano X can be found here.

Phishing attacks

At their heart, phishing attacks are an attempt to exploit trust. They trick you into leaking credentials, divulging confidential information, downloading malicious code, sending money, etc. Often they will attempt to create a sense of urgency, for financial or safety reasons, which may override your natural skepticism. Spear phishing attacks are like normal phishing attacks, except that are tailored to the specific target; they require more effort on the part of the attacker, but can bypass normal skepticism on the part of the target, and are therefore more effective.

The playbook

All the attacks we have witnessed so far against our ecosystem play by this book:

  1. Phishing and social engineering: someone will reach out to you, impersonating someone you might know, and invite you on a call, try to hire you, ask for your help on a development project, etc.
  2. Local device compromise: the short-term goal of the attacker is getting you to download/execute something which will compromise your device. For instance:
    1. They'll tell you to copy/paste something to "unblock a web-page" (hint: that "something" will hack you).
    2. To "update your audio drivers" or your "Zoom SDK":
      1. Then replace your Chrome wallet with a fake so that if you sign using a hardware you will send funds to the attacker. (use X's translate feature to read)
    3. To "update your Meet/Zoom client"
  3. Secrets and crypto gone: A compromised device is game over. The attacker will steal all your passwords, drain your wallets, and Telegram/X accounts.
  4. Lateral movements: the attacker will start impersonating you to infect more targets.

What to look out for

  1. Be extremely suspicious when someone reaches out through an unusual channel, e.g. if you usually chat on Slack and they are reaching out on Telegram, or someone sending you a random Calendly invite. If you have doubts, always double-check through another way (e.g., Slack or Signal) to make sure you are talking with the right person.
  2. Be extremely suspicious when someone pressures you into downloading or executing something. It doesn't matter if you are late to a meeting, if you are trying to make a sale, or if your boss is pressuring you. Don't fall to the percieved sense of urgency. Do not download any update/driver/or execute commands, and reach out if you think something weird is happening.

How to protect yourself

You MUST check email domains and headers before clicking on any links or taking any potentially compromising action, like divulging information or sending money.

In Gmail, there is an upside down triangle by the "to" line that when clicked will show details of the senders and recipients; check that the domain of the sender is as expected. To the far right of the sender line is a three-dot drop down menu, with an option for "Show original"; this will show the full headers and raw text of the message. Verify that all addresses and links are as expected.

Other than that, you MUST follow the recommendations in this book. Crucially:

  1. No software wallets: you MUST NOT store wallet / seeds on your machine under any circumstances. Use hardware devices, such as a Ledger X.
    1. If you need to share a wallet with a team member, do a 1/N on Asigna backed by a Ledger device instead of sharing the seed with your colleagues.
    2. For very small amounts (e.g., <1000 USD), you MAY use a wallet app on your phone. You MUST download it from the App Store and make sure that is not a scam wallet).
  2. MFA everywhere: you MUST enable multi-factor authentication on ALL your work services. You MUST use Yubikeys (hardware security keys) for second factors. You MUST NOT store the second factor in a password manager.

Work devices

A separate work laptop allows you to keep your work and life separate, without having to worry about privacy or attacks spilling over your your personal accounts.

When under stress the minute you discover your work account has been hacked, you don’t want to also be worried about securing your personal finance, your network perimeter, your family devices, etc. We have been through this and it is not nice.

A work laptop also allows clearly separating the online identity you use for work and outside of it. For instance, it allows to easily create and use new accounts (GitHub, X, etc) for work, without having to constantly log-in and log-out or use separate browser profiles. For those of us who want to keep a reduced online footprint (e.g., do not link my personal X account with the one I use for Stacks) this also reduces the likelihood of using the wrong account in the first place and reveal the connection. For developers, a separate work device means separate CLI/git/SSH configuration, which could otherwise be very painful to manage.

Context

State-sponsored attackers

Our industry is continuously targeted by state-sponsored attackers that use this playbook:

  1. Spear phishing
  2. Local device compromise (including Telegram accounts, 1Password passwords, etc.)
  3. Steal crypto
  4. Spread and repeat

We have seen this happening

We have witnessed multiple attacks against the Stacks ecosystem, ranging from developers being compromised when pulling and executing code from GitHub (even from internal repositories) to users falling victim of phishing and being tricked into executing malware on their devices.

The range of these attacks is wide and sophisticated and, as our ecosystem grows, the probability of succeed will only increase (due to an increased attack surface).

How to fight back

We need to take steps to prevent this from happening, and implement better security strategies, roll out coordinated policies and ensure that everyone is aligned on what to do and what to avoid (e.g., keep your MFA on a Yubikey and nowhere else).

Deploying hardened laptops

Our strategy is based on the Swiss Cheese Model. Hardened laptops ensure an additional layer of defense to keep us all safe.

One important part of hardening a laptop is to enable full disk encryption. This prevents an attacker from accessing the hard drive directly, either to read data or implant malware. In order to maximize the effect of disk encryption, a strong password MUST be used.

Endpoint Detection and Response (EDR)

“Endpoint Detection and Response” or EDR is a fancy, enterprise term for a software that runs on your laptop and helps keeping it safe. Companies in the ecosystem SHOULD pick an implementation that can be configured such that it will yield low false positives (e.g., it shouldn’t flag running bitcoind as malicious) and a good security posture. In other words, it will do its job and get out of the way, for all of us to do ours.

EDR SHOULD NOT prevent you from doing things your way (e.g., installing homebrew), but it SHOULD protect you in case a homebrew package gets backdoored and tries to execute a malicious payload.

Why are we pushing for an EDR?

You SHOULD pick and configure an EDR to do the following:

  1. Alert your organization in case of anomalies (e.g. a debugger attached to a password manager, a process enumerating files, uploading your home directory somewhere, etc.).
    1. This will tell your organization when someone is hacked right away, giving yourselves a chance to jump ahead of the attack (e.g., disabling users, rotating keys, etc.).
    2. Without it, you would typically discover the hack when it’s too late.
  2. Prevent some attacks altogether.
    1. EDR is no magic bullet and won’t stop 0-days or very sophisticated attacks.
    2. You SHOULD ONLY deploy a solution that protects against all malicious payloads we have seen used in web3.
  3. Send an audit trail to a remote server.
    1. This way, if someone gets hacked and the attacker deploys anti-forensics measures to cover their traces, you will still have trace of what happened on the machine.
    2. With more visibility, comes more power to contain the attack and stop it from spreading. Without EDR, you will be running in the dark trying to figure out what the attacker did.

Software updates

You MUST keep your devices and applications updated. This will prevent attackers from using recently disclosed vulerabilities to compromise you. Such attacks are much more likely than those that use zero-day vulerabilities, which are almost certainly more valuable economically than anything which can be gained by compromising you.

In order to keep your devices and applications updated, you MUST turn on automatic updates. You MAY choose to only download and notify, or automatically install. You MUST do this for the operating system on EVERY device, and for EVERY application which is not updated with the operating system.

Unfortunately, operating system vendors often stagger the release of updates to vulerable devices; it may be hours, or even days, before your device will be automatically updated. To prevent this, you SHOULD subscribe to the relevent security update email list for your operating system vendor. This way you will be notified immediately once updates are available.

Apple devices

Configuring automatic updates

All Apple operating systems have a Settings application, which has a General tab, the second item of which is Software Update. If you open this, you will see an item for Automatic Updates. You MUST at least set your device to download updates. You SHOULD configure automatic installation of Security Responses. You MAY configure automatic installation of operating system updates, though it's reasonable to not enable this; if not, you MUST subscribe to the security-announce email list and install manually at your first opportunity.

Subscribing to the security-announce email list

In order to be notified immediately when updates are available, subscribe to the security-announce email list.

For developers

Developers are a particularly vulnerable target for exploitation, since they must download and run code as part of their daily routine. Most attacks begin by exploiting developers, and then attempt to move laterally within and without the organization.

One specific attack vector to be aware of is fake interviews. These have targeted both internal and external developers in the ecosystem. This allows the attacker to request that a developer downloads a repository from GitHub (or similar), which is then used to infect the developer's machine. Any locally stored credentials are extracted and exfiltrated; cryptographic wallets are drained, and exploit code is uploaded to any repository for which the developer has access.

Another attack vector which has often been employed against developers is the watering hole attack. This targets resources which many developers are known to use, and can include anything from source repositories to coding help sites. Examples include widely used Javascript packages on NPM, ads on websites like StackOverflow, etc.

How to protect yourself

  1. You MUST follow these guidelines to avoid being phished.
  2. You MUST use hardware backed SSH keys when interacting with GitHub.

SSH keys

Developers MUST use SSH keys which are backed by hardware security keys when interacting with GitHub. While it is possible to use an SSH key backed by a GPG key, a YubiKey allows having multiple SSH keys on a device, and the configuration is much more streamlined.

Setup

SSH

Use your package manager to install OpenSSH (use brew for MacOS). See this for more details.

YubiKey

You MUST set a PIN on your YubiKey.

Generate a key

Use ssh-keygen with the following args to create a key backed by the hardware device. If you plan to store multiple ssh keys on your hardware device, you SHOULD ALWAYS identify the key using the -O 'application=ssh:UID' argument. The UID part is used internally on the card to specify in which slot to store the key, replacing the -C comment field, and is exported when regenerating keys on other devices.

The command for creating such keys will look like the following:

ssh-keygen -t ed25519-sk -O resident -O verify-required -O 'application=ssh:function-CARDNO'

You SHOULD structure your UID strings as function-CARDNO, where function is what the key will be used for, and CARDNO is the YubiKey serial number. You SHOULD NOT simply keep the string function-CARDNO.

You SHOULD NOT specify a password when creating the key, since it will only be used to lock the empty file on the filesystem.

Update the file permissions:

chmod 600 ~/.ssh/id_ed25519_sk

Regenerate a key on a separate machine

You MAY use this hardware backed SSH key on multiple machines. To do so, you MUST regenerate the key files on each machine:

cd ~/.ssh/
ssh-keygen -K

As before, you SHOULD NOT specify a password.

Sharing Secrets

In General: Don't!

Developers should NOT share secrets with each other (or anyone else) unless absolutely necessary.

When using secrets to authenticate to systems programmatically (such as GitHub CI or 3rd party APIs), prefer short-lived authentication tokens based on OIDC (or a similar protocol).

For Exceptions, Use Approved Tools

In rare cases, you will need to share a short-lived secret with another member of your organization. For example: when provisioning a new account for a user and providing them a temporary, first-login password (which should be immediately changed after logging in).

In these situations, use the company adopted and approved secrets management tool to create and share secrets via short-lived, "self-destructing" links.

When creating these links, follow these best practices:

  • Get on a video call with the party who will receive the secret and verify their identity before proceeding
  • Create a short-lived and self-destructing link live while on the call with the recipient
    • Ensure that this link is very short lived (use the minimum time offered by the tool, such as 5, 10, or 15 minutes)
    • Ensure that this link can only be viewed the minimum numbers of times that the tool offers before expiring (ideally 1 time)

Best Practices

  • ALWAYS verify the identity of the recipient via video call before proceeding to share a secret.
  • ALWAYS be vigilant and suspect phishing attacks.
  • NEVER share secrets via communication tools (For example: Signal, WhatsApp, Slack, Discord, Telegram, etc.).
  • NEVER share secrets with ANYONE outside of your organization.

Trust your gut. When something feels off, immediately stop what you're doing and inform your manager as well as the CTO. They will help you assess the situation and take any appropriate actions to safekeep our organization.

For administrators

Separate admin accounts

GitHub hardening

Since the Stacks ecosystem does the bulk of its development work in public repositories, it is crucial that those repositories be hardened against attack. Any weakness in their configuration exposes our developers and users to attack vectors, as we have seen in previous attacks against the ecosystem from nation-state sponsored attackers. The following policies MUST ALWAYS be implemented on EVERY repository. If your organization has an Enterprise GitHub account, you can set this up at the org level and have it apply by default to all repositories.

Commit signing

git does not, by default, do anything to verify that a commit comes from the user whose email address is tied to it. This address is simply metadata, and a compromised developer machine can alter this data at any point in the commit/push process; we saw exactly this in previous attacks.

To combat this, you MUST require signed commits on your repositories. You SHOULD require all users to enable vigilant mode, which adds an extra layer of obviousness when commits are unsigned. This will prevent one infected developer from impersonating others.

Branch protection

The main branch of a repository is the source of truth for external users, and where releases are normally taken. So you MUST protect that branch against common problems, regardless of whether those problems arise from malice or simply negligence.

First, you MUST disable force pushes against your main branch. This prevents an infected developer from altering the history of a branch, in order to hide a malicious commit by making it appear to have happened in the past.

Next, you MUST require all changes to your main branch to go through the pull request process. You SHOULD require two or more approvals for each PR. You MUST require dismissing stale reviews, i.e. when new code is pushed.

Finally, you MUST protect the main branch from deletion.

CI

Continuous integration is a powerful tool for preventing regressions in code, and allows us to make changes without unexpected side effects. However, CI MUST be hardened in specific ways to avoid causing other problems.

  1. You MUST NEVER include secrets in CI! Instead use the github secrets APIs, which allow fine grained access control. This can for example limit access to specific jobs run by specific people.
  2. You MUST use OIDC for backend to backend authentication. This allows the use of limited and expiring tokens in the place of passwords.
  3. You MUST require reviews for deployments, and use environments. This limits the blast radius of any compromise, preventing infected code from reaching users.
  4. You MUST pin actions to specific versions using the SHA.
  5. You MUST specify permissions used by all workflows, limited to the minimum needed to run.
  6. You SHOULD use zizimor to vet CI workflows.
  7. You SHOULD NEVER use pull_request_target, since in a public repo anyone can submit a pull request from a fork.

Email hardening

Physical security

Traveling

Traveling exposes you to special risks, like the Evil Maid Attack. This attack involves a malicious actor gaining access to one of your devices through an official role, and then using that access to steal data or implant malware. It is not limited to maids in hotel rooms, but rather any time any device is out of your control. This includes coffee shops, conferences, airport security, customs, shipping, etc. As always, though, we should keep in mind our threat model, unless we have specific reason to worry about 1% attack scenarios.

Common attacks

Physical

  1. You SHOULD keep a low profile.
  2. You MUST NEVER leave a device unlocked AND unattended.
  3. You MUST use full disk encryption on any device which supports it (with a strong password)!
  4. You SHOULD power devices off before leaving them unattended, not simply lock them; this prevents a lockscreen compromise from granting access to the unencrypted disk contents.
  5. You SHOULD choose hotels which have in-room safes, which will reduce the number of people who have access to your devices while you are at dinner or the pool.
  6. You MAY use a screen protector to mitigate shoulder surfing.

Network

  1. You SHOULD use a VPN when using WiFi.
  2. You MAY get a local SIM (eSIM is easier than physical SIM card) if you don't have a global carrier; but even then a VPN will protect you against some attacks (e.g. stingrays).

Uncommon attacks

Mitigating uncommon attacks often requires extreme measures, which will impact your ability to do work. Always remember your thread model!

  1. You MAY choose to engage Lockdown Mode, available on Apple and Android devices. Read the documentation carefully if you do so, since the behavior is very different by platform.
  2. You MAY choose to wipe your devices before flying, or crossing international borders. Be aware that this may make you look suspicious, which could result in reprecussions not limited to interrogation and/or confiscation of your devices.

Contacts

For questions or concerns about the security handbook in general, or user-specific security in particular, please contact:

security@stackslabs.com