Blog

There is a quiet assumption sitting behind almost every account you own: that if you ever lose your way in, your email will let you back. Click "forgot password," wait a moment, and something arrives in your inbox that puts you back in charge.

It is a reasonable way to build things. It also means your mailbox is not really one account among many. It is the drawer where the spare keys to the others are kept, which makes it the one account worth being fussy about.

So here is the fussy version. What the options actually do, which of them hold up against a convincing fake login page, the one feature that quietly undoes the rest and how to switch all of it on.

TL;DR

• Use a passkey or a hardware security key if your provider offers one. They are phishing-resistant in a way that SMS codes and authenticator codes are not.
• Use an authenticator app if it doesn't. Enormous improvement over nothing. Still phishable.
• SMS codes are the weakest real option. NIST's current guidelines classify exactly one authenticator as restricted, and this is it.
• Save your recovery codes somewhere that is not the inbox they unlock. Locking yourself out is a very real way to lose an email account.
• App passwords bypass your second factor completely. That is their entire job. Create one only when a client demands it, keep it to one per device and revoke it when you are done.
• Your recovery address and recovery phone are keys too. A locked front door and an open window is not security.

Why the Inbox Is the Wrong Thing to Secure Casually

Almost every account you own has a button that says it will email you a way back in. That is sensible design. It also means that for a great many of your accounts, the real lock on the door is your mailbox, however strong the password on each individual one happens to be.

Attackers worked this out long before users did. Taking over an inbox is not usually the goal. It is the tool. Once somebody is reading your mail they can trigger resets, collect the codes, approve the changes and delete the warning messages on the way out, without ever having to attack the accounts they actually want.

So if you are going to be fussy about exactly one account, make it this one. Everything in this article is worth doing on your email before you do it anywhere else.

What People Mean When They Talk About 2FA

There are four of them in common use, and they are not equivalent. The gap between the best and the worst is wider than most people assume.

A code by SMS. The provider texts you six digits. Better than nothing, and worse than every other option here. The weakness is not the code, it is the phone number. Numbers get moved to a new SIM by somebody who has talked a carrier employee into it, and your codes move with them. The problem is real enough that the FCC adopted rules in November 2023 requiring carriers to authenticate customers properly before a SIM change or a port-out, and to offer you a free account lock against both. NIST's 2025 authentication guidelines go further: use of the phone network for out-of-band verification is classified as restricted, and at publication it was the only restricted authenticator in the document. Services may still offer it, but they have to provide something better alongside it and tell you about the risk.

A code from an authenticator app. A six-digit number that changes every thirty seconds, generated on your device from a shared secret. No phone number, no carrier, no text message to intercept. This is a very large upgrade, and for most people it is the realistic default.

It has one specific weakness worth understanding, because it is the weakness that catches people who thought they were safe. Typing a code into a web page does not tie that code to the real site. NIST puts it plainly: manual entry does not bind the output to the session, so an impostor verifier could relay it. In practice, a fake login page that looks right can collect your password and your code, pass both to the real provider inside the thirty seconds they are valid, and let itself in. Ready-made tooling for exactly this has existed for years. An authenticator app defeats password reuse, credential stuffing and opportunistic attacks. It does not defeat somebody who has got you onto a convincing fake page.

A push notification you approve. Your phone asks "was this you?" and you tap yes. Convenient, and vulnerable to the oldest trick in the catalog: send the prompt over and over at eleven at night until the human taps approve to make it stop. The better implementations use number matching, where the login screen shows you two digits that you have to type into the app. That kills the half-asleep approval, and it is worth turning on wherever you are offered it. Against a live fake-page attack it is in the same boat as an authenticator app.

A passkey or a hardware security key. This one differs in kind rather than in degree, so it gets its own section.

What a Passkey Actually Is

A passkey is a pair of cryptographic keys. The private half stays on your device or in an encrypted credential manager and never travels to the site you are signing into. The site keeps only the public half, which is useless to a thief. When you sign in, your device proves it holds the private key without ever revealing it.

The part that matters for phishing is less obvious and more important. When a passkey is created, it is bound to the exact domain that created it. A passkey you made for your bank will not answer a request from your-bank-secure-login.example, no matter how perfect the copy of the page is, because your browser will not even offer it. NIST calls this verifier name binding, and names WebAuthn, the standard passkeys are built on, as the example of how to do it.

That is the whole argument, so it is worth reading twice. With an authenticator app, your safety depends on you noticing the fake site. With a passkey, the fake site gets nothing even when you do not notice. The decision has moved from your judgment at eight in the morning to a check your browser performs every single time without ever getting tired or distracted.

Two honest drawbacks, both smaller than they were a year ago and neither of them gone.

First, a synced passkey puts part of your security in the hands of a credential manager and its account recovery. Moving them used to be close to impossible. That has improved: Apple's iOS 26, iPadOS 26 and macOS 26 releases and recent Android versions support transferring credentials directly between credential manager apps on the same device, and Apple Passwords, 1Password, Bitwarden, Dashlane and others have adopted it. The underlying work is only half finished, though. The exchange format reached proposed-standard status in 2025, while the protocol for actually moving credentials between providers is still a working draft that explicitly says it is not a basis for implementations. Same-device switching between participating credential managers works today on both Apple and Android. What does not exist yet is a finished universal protocol for moving credentials freely between providers across different devices and platforms.

Second, support is uneven. Microsoft began making new consumer accounts passwordless by default in 2025 and most large providers accept passkeys somewhere, but plenty of smaller services still do not offer them at all. A physical security key sidesteps the ecosystem question completely, at the cost of being an object you can lose. Credentials cannot be exported from a certified hardware key by design, so there is no migration path and the answer is to buy two and register both.

Where a passkey is on offer for your email, take it.

App Passwords: The Back Door You Opened Yourself

Now the part that is mostly missing from articles about securing email, and that can undo everything above.

Turn on two-factor authentication, then try to set up your mailbox in an older desktop mail client or on an office printer. It fails, and the reason is structural. When an older mail client connects over IMAP or SMTP using traditional password authentication, it hands over a username and a password, and there is no interactive moment in that exchange where the server can stop and ask you for a code from your phone.

The modern fix is to stop using a password at all. RFC 7628 defines OAuth-based authentication over these protocols for exactly this situation: the client sends you through a browser login where two-factor happens normally, then receives a token it uses from then on. This is what "modern authentication" means in Gmail and Outlook, and it is why those accounts work properly in current mail apps.

The older fix, still available at many providers, is an app password. Your provider generates a long random string that works in place of your real password and skips your second factor entirely. Google's is sixteen characters, shown to you exactly once. You can only create one if two-step verification is already switched on, which is the quiet irony of the feature: it exists only for accounts that took security seriously, and what it produces is a credential that ignores the protection they switched on.

Google itself says app passwords are not recommended and are unnecessary in most cases. That has not stopped them being widely used, and it has not stopped them being targeted.

In June 2025 the Citizen Lab published a report on a campaign that did precisely that. Over at least ten email exchanges, an attacker posing as a US State Department official cultivated a relationship with Keir Giles, a Chatham House specialist on Russian information operations. Four apparently fabricated state.gov addresses were copied into the thread for credibility, which worked partly because the real State Department mail server appears to accept messages to addresses that do not exist without bouncing them. Eventually a professionally formatted PDF arrived with instructions for joining a government platform. The instructions walked him through creating an app-specific password on his Google account, labeling it with a meaningless string and sending it back.

The PDF contained no malware. There was no exploit anywhere in the operation. The entire attack was a set of polite instructions that persuaded a careful, security-aware target to generate a credential that bypassed his own two-factor authentication, and then to hand it over. Google's threat intelligence group attributed the operator to UNC6293, linked with low confidence to APT29.

The rules that follow are short:

• Create an app password only when a device truly cannot do anything else, and look for an OAuth option first.
• One per device, named for that device, so you can revoke precisely.
• Revoke it the moment you stop using that client, sell the phone or replace the printer.
• Never send one to anybody. There is no legitimate situation in which a person, a company or a support agent needs your app password. None.
• Google revokes its app passwords when you change your account password. Do not assume every provider does. After any scare, change the password and then go and audit the app password list separately.
• Audit that list occasionally anyway. Old app passwords have a habit of surviving long after the device they were created for is gone.

Recovery Codes Are the Part Everyone Skips

When you switch on two-factor authentication you are handed a list of one-time codes and a button to download them. Do it. NIST calls these look-up secrets and treats them as a legitimate authenticator in their own right, with the caveat that they are not phishing-resistant either.

The reason to care is not heroic. A very ordinary way to lose access to an email account is a phone that went into a canal carrying the only copy of the authenticator secret. Recovery codes are the answer to that, and they are the step people reliably skip, because the account works perfectly well without them right up until it does not.

Where to put them: printed on paper somewhere a burglar would not think to look is perfectly reasonable. A password manager is good too, with one trap worth thinking through. If your password manager's own account recovery runs through the email address these codes protect, and the codes exist only inside that password manager, you have built a circle with no way in. Keep at least one copy outside the loop.

And do not store them as a draft in the inbox they unlock, which is a thing people do.

The Windows You Left Open

Two more ways into your mailbox that are not the front door.

Your recovery address and recovery phone. These exist to let you back in, which means they can let somebody else in. An abandoned address at a provider you no longer check, or worse, one that has lapsed and could be registered by anybody who notices, is a live key to your current mailbox. Go and look at what is actually listed. This deserves a piece of its own and will get one.

Forwarding rules and filters. This is a standard move after a mailbox compromise and one that is easy to overlook. A rule that quietly copies everything to an outside address, or files all mail from your bank into a folder you never open, survives the password change, the new second factor and the warm feeling of having dealt with it. If you ever suspect something happened, read your rules before you relax.

Turning It On: Your [@fuck.it] Account

This is the login you use for your subscription, your invites and your profile page.

1. Sign in at fuck.it and open your account settings.
2. Find the security section and switch on two-factor authentication.
3. Scan the QR code with any authenticator app. Anything that does standard TOTP works, and you are not tied to a particular vendor.
4. Type the six-digit code once to confirm. If you skip this step, it is not actually on.
5. Save the recovery codes. This is the step that matters most in a year's time.

Turning It On: [@fuck.it] Webmail

Your mailbox has its own login and its own second factor, which is a separate thing from the account above. Switching one on does not switch on the other, so do both.

1. Sign in to your webmail.
2. Go to Settings › Security.
3. Switch on TOTP and scan the QR code with your authenticator app. Any standard authenticator app will do.
4. Confirm with a code to finish.
5. Store whatever backup or recovery code it hands you, in the same place you put the others.

Hardware security keys over WebAuthn are not supported on webmail yet, so an authenticator app is the strongest option here for now.

One thing worth understanding while you are in there. A mail client using traditional password authentication over IMAP, POP3 or SMTP has no interactive moment where the server can stop and ask you for a code. Providers deal with that in different ways: some disable password authentication once a second factor is enabled, some issue separate application passwords and modern services increasingly use OAuth so that the second factor can happen during a browser login instead.

The practical conclusion matters more than the mechanism, so find out what credential your mail apps are actually using. If your normal mailbox password still works over IMAP, POP3 or SMTP after you switch on two-factor authentication, then that password is still a way into the mailbox with no second factor standing in front of it. Make it long, make it unique to this account and never reuse it anywhere else.

The Twenty-Minute Version

In order, because the order matters:

1. Email first. It is the recovery channel for a disturbing number of your other accounts, so securing them while the mailbox is open is largely decorative.
2. Turn on the strongest second factor on offer. Passkey or security key, then authenticator app, then SMS. If SMS is the only option, take it and ask your provider why.
3. Save the recovery codes. Somewhere physical, outside the loop described above.
4. Review your app passwords and connected apps. Revoke anything you do not recognize or no longer use.
5. Check your forwarding rules and filters. Takes a minute, almost never done.
6. Fix your recovery address and phone. Make sure both are things you still control.
7. Then do steps two and three for your password manager and your phone's cloud account. Those are the other two sets of spare keys.

That is the lot. One short session on the sofa, once, for the account that holds the spare keys to so many of the others.

Where [@fuck.it] Lands

Both of your fuck.it logins support two-factor authentication with an authenticator app, and the setup steps for each are above. Hardware keys are not there yet, and we would rather write that sentence than imply otherwise and let you discover it later.

Here is a number from our own records, since we are in a position to look it up and most people writing about this subject are not: fewer than one in five of our paying customers has it switched on.

Sit with that for a second. Our customers are, by definition, people who went looking for a private email service, found an invite-only one and paid money for it. If adoption is that low among people who are actively paying for privacy, it says something uncomfortable about how badly an optional security feature loses to inertia, no matter how motivated the person is.

Which is the honest note to end on. We can filter the dangerous mail, run the infrastructure properly and never sell what is inside your mailbox to anybody, because your subscription is what pays for it rather than an advertiser. What we cannot do is make an optional second factor protect you if you never switch it on.

It takes about four minutes per login. Go on.

---

Sources & further reading: NIST SP 800-63B-4: Authentication and Authenticator Management · NIST: Authenticators and phishing resistance · NIST: Syncable authenticators · W3C Web Authentication (WebAuthn) · RFC 7628: SASL Mechanisms for OAuth · Citizen Lab: Same Sea, New Phish · Google: Sign in with app passwords · FCC: SIM swap and port-out fraud rules · Open-Xchange: Application passwords

Related reads: Is It Safe to Click Unsubscribe? · Not Today, Scammer