(Pt 1) Schemes for the Passwords you Don't Put in the Password Manager

The correct answers regarding passwords are the following:

  1. Prefer key authentication, such as with SSH, when possible.
  2. Use TOTP 2FA when possible.
  3. Use a password manager, with strong (highly entropic) and unique passwords.

This is all fine and dandy, but what about your computer? Your phone? Your password manager itself? These are passwords you do not store in your password manager, and you should memorize strong and unique passwords for these.

Keeping in mind that choosing a good password is not necessarily about having high entropy. A highly-entropic source could generate "password!123" as a random, twelve-character password. The actual goal is to choose a password that your attacker is very unlikely to guess.

In practice, the attacker wants to construct a distribution $P$ of passwords you are most likely to have, and you want to anticipate this to choose a password from the complementary distribution $P'$. It's just the case that a dedicated attacker is usually much smarter than you, and by trying to anticipate what $P'$ is, you are more likely to choose a password higher up in the ranking implied by $P$ than if you just went with a long, random one to begin with.

With all that said... You still need to memorize some passwords. Deriving passwords has worked well for me and many others before adopting a password manager.

There are three main choices:

  1. Write the password down
  2. Derive a password for these through a scheme, or
  3. Just memorize random passwords.

This post is part one of a two parter. Part two has an improved actual password scheme, which is upcoming!

tldr:

Password managers and 2FA are great, but you still need to memorize some passwords (such as the one to your laptop, your phone, or to your password manager). Assuming you don't write these down, how can you remember all these?

Password derivation schemes might provide ~7 bits of true entropy, and many more bits of "apparent" entropy, relying on the obscurity of the derivation scheme. This falls apart in the face of an adversary that gets even just one of your passwords, or an adversary that is smarter than you who can anticipate your scheme. It is a good bet to make that any given adversary will be smarter than you.

We need a scheme which is low on the mental burden of memory, for which compromising one password does not necessarily compromise the rest. We can improve on memorizing unique entropic passwords.

Some memory tricks include preferring words over random strings (for the same amount of entropy), and using capitalization and numbers-as-delimiters to get some extra entropy. Those help, but still, we can do a little better than memorizing N-passwords for N-devices.


Writing down passwords is risky. Memorizing many random passwords is good but difficult.

tldr: Besides password managers, some people write down passwords (which can be good!) Another opportunity is just to memorize unique, entropic passwords, but this depends on having a strong memory. This does not scale well if you have multiple devices.

Writing the password down is actually pretty good. This lets you set up an arbitrarily strong password without worrying about memory, and the risk model is apparent to anyone: People who live with you, or who can break into your house, can get your passwords. The benefits are also apparent: If you suffer a brain injury or die, the passwords persist. Further, there's no risk that your notepad of passwords can be stolen in a digital hack.

Let's assume you've already considered writing down your passwords, and that won't cut it.

Just memorizing random passwords is another choice. Let's say a given person can memorize 72 characters worth of random passwords. This is enough to dedicate 24 random characters to your password manager, 24 random characters to your desktop/laptop, and 24 random characters to your phone. At about 6.55 bits per character, this brings us to 157 bits of entropy per password. So, this is good enough by a lot.

But that requires a hefty memory! What if people could only memorize 36 characters? That brings us to 78.5 bits, which might not be enough.

Let's assume they can still only remember $N=36$ random characters worth of entropy, or about 240 bits. This lets us account for entropy in the form of random words or random characters alike.

Just memorizing passwords is difficult to recommend. What if you also need to memorize, say, passwords for your work phone and laptop? And for a volunteer phone and laptop? Bank pins? What if you have a bad memory and you need to stretch it for a dozen devices?

"Deriving passwords" lets you get extra entropy 'for free' without burdening your memory. But you can lose most of that entropy with just one leak.

tldr: If you can keep your password derivation scheme private, you can have passwords which might appear highly entropic. But this relies on security by obscurity. Just one leaked password compromises the rest of them. In this example, a password with 165 bits of entropy drops to less than 60 bits of entropy with a compromise of just one other password.

So, people might instead derive a password. There are many ways someone might construct this, but I usually see two or three of these components:

  1. Use as input the name of what you're signing into.
  2. Have a highly entropic "base password" that is used in the password.
  3. Have a highly entropic "extra password" that is used in the password.

Remember the hacker's distribution $P$? The "derive a password" strategy is one with the intention of generating a password deterministically in a way that has a higher apparent entropy than there is. The apparent entropy is the measure of how much lower the given password is in the attacker's distribution $P$. That is to say, the n-th password the hacker would guess has an apparent entropy of $log_2{n}$.

"Apparent entropy" is not a term-of-art, by the way. It's a term I made up and didn't end up publishing. It's the best way I know to articulate the idea that these password-derivation techniques do provide some security, against the "normal" case of an attacker using hashcat against a leaked corpus of hashes. My game theory is rusty but I am certain the idea of "apparent entropy" must exist in the literature. If there is such a term or framework, please email me!

Anyways, let's look at an example of how this works:

For example: Someone is logging in to their laptop.

This person can remember 36 random characters. With one "base" password and three logins (laptop, password manager, phone), they dedicate 9 characters to a "base" password, 9 characters to an extra per-login password, and they also derive extra components from the name laptop.

Their BASE PASSWORD is the same across all devices and is randomly generated: Q-R!yFqq-

Their EXTRA PASSWORD is unique to their laptop: 2DkF!pEEq.

Finally, they derive a pattern from the first three characters LAP, by drawing a spiral on the keys: L yields l;po, A yields aswq, and P yields p[-0.

Their password is Q-R!yFqq-2DkF!pEEql;poaswqp[-0.

Traditional security advice will tell you the derived parts provide no entropy, but it's almost certain an attacker would guess Q-R!yFqq-2DkF!pEEql long before they guess Q-R!yFqq-2DkF!pEEql;poaswqp[-0.

(Except for the fact that string appears in this very-publicly-online text post!)

Using the name of what you're signing into (e.g. "phone", "laptop", "1password") carries with it extra decisions: Do you input the whole name? Do you use the first 1, 2, 3, 4 characters? Maybe you map the characters to a pattern on the keyboard, or the phonetic alphabet, or some personal lookup table? And the order of these elements matter: Input, base, extra? Base, input, extra? There are three such orderings, so this gives us about 1.5 bits of entropy "for free", since they presumably don't burden ones memory.

For the decisions someone has to make when deriving a pattern. This gives us more "free" bits of entropy: Two bits of entropy for choosing how many characters (1, 2, 3, or 4) to use from the input, and another bit of entropy for choosing whether to pull from the front or the back.

Let's assume the user is not memorizing a lookup table, and is choosing one of a few obvious QWERTY-based patterns. The actual pattern might add, generously, 3.5 bits of entropy to make for a total of seven bits of entropy total from decisions on how to derive the password. Again, this is "free". But seven bits of entropy is about the same that you get for just one extra character.

The main benefit comes from the apparent entropy from the derived string. In the example above, l;poaswqp[-0 technically provides zero bits of entropy for being deterministically generated. But if it would take an attacker one trillion more guesses after Q-R!yFqq-2DkF!pEEq to guess Q-R!yFqq-2DkF!pEEql;poaswqp[-0, that would provide almost 40 extra bits of apparent entropy!

This all relies on security by the obscurity of your strategy, making a more rigorous analysis elusive. Security people are oft to deride any security-by-obscurity schemes, and for good reason. If just one of these passwords leak, or even two, you can kiss all that extra entropy goodbye for your other passwords. You miss the 7 bits of entropy from the derivation scheme, the ~40 bits of apparent entropy from your pattern, but importantly, you also lose the base password. So, you lose ~58.9 bits from the base password, ~39.9 bits of apparent entropy, and ~7 bits of entropy you get for free from the details of the construction. So, you move from 165 bits of apparent entropy to merely 58.9 bits of entropy from your "extra" password.

Geeze, passwords sound impossible.

tldr: Solving this problem requires some kind of derivation scheme which (1) does not rely on obscurity of the scheme and (2) does not compromise every other password if just one leaks.

The problem is as follows:

  1. People still need to memorize some passwords.
  2. People have limited capacity to memorize these passwords.
  3. Existing derivation schemes are crippled if one password (or even just the scheme) gets leaked.

I, personally, have to memorize passwords for two phones, a laptop, a desktop (decryption key and sudo), my servers, and (formerly) a work laptop.

For my phones, one is a "throwaway" phone and only has a long pin. My primary phone also has a long pin. Both of which are protected by hardware modules which make it difficult to brute-force the password. For my work laptop, it demanded a new password every few months, so my password was unique and weak.

But I am still left with six random passwords I need to memorize!

Memory tricks before we get to the password scheme

tldr: If you are character-limited, I think it's better to use random lowerchase characters, and to memorize them using a song, poem, or phrase.

Other than that, just go with random words! It's the easiest.

A user can memorize a password they use every day by writing it down, and destroying the password element-by-element.

I have difficulty memorizing long strings with random punctuation. One gets 4.70 bits-per-character for the set of lowercase characters, up to 5.17 if you add numbers, and up to 5.95 bits per character if you include capital letters. You need two symbols to make that a perfect 6.0.

Further, though the idea of memorizing 72 random characters is scary, I still remember Jingle Bells and The Declaration of Independence and most of Hamlet's To Be or Not To Be soliloquy. Socrates famously rallied against writing, instead preferring people rely on their own memory. The oral tradition is what carried knowledge on, and music and poem is the way that was done.

So, I argue for memorizing more characters from a limited set by writing a poem about it. It helps if you happen to know other languages. This is something meant to get more entropy-per-memory-burden. It's not based in any actual research.

But I'd say just go with random words. 1passwords wordlist is 18325 words long, which comes out to about 14.16 bits per word. The average word is 6.2 characters long and the longest is 9, so even a conservative 63-max character password gets 99 bits of entropy at minimum with seven words.

To memorize a long password the user will use every day, they can start by writing it down, and destroying one element each day as they commit each word to memory. How to commit something new to your memory is up to you to figure out.

So, what's the scheme?

That's for part two! I'm still writing it! :)i

Digital minimalism through two smartphones works for me

tldr: Your phone is online and going online is distracting. Instead of replacing your smartphone with many bulky purpose-built devices, consider using an old smartphone that you keep offline.

I do this and it works very very well for me, using an old iPhone 13 Mini running iOS 18. The battery lasts a long time in Airplane mode.

My relationship to technology as a consumer is atypical.

I did not own a cell phone until the age of 17, while my peers acquired theirs mostly in elementary and middle school. I did not own a proper smartphone until the age of 19. I don't have play games on my phone, I don't use and never have used "short form video content" apps like TikTok or Instagram Reels, and I don't have algorithmic feeds (besides the frontpages of Lobste.rs and Hacker News). I only get notifications for messages, and my phone stays on "do not disturb" at most times. I don't have a problem with "smartphone addiction". I don't even like to listen to music in the background.

And yet, I have the same problem many others have: I also get distracted by my phone.

The reason is that I have an iPhone 16 Pro, and when I put myself to the two-handed task of heaving this towering behemoth and meeting its gaze long enough for the Facial Recognition to meander upon my features and grant me entry, I find myself inclined to complete other tasks: Checking emails, catching up on my Mastodon feed, responding to people, opening up an Internet Browser, or any other myriad minutia.

This giant internet-connected Apple phablet breaks ones piece of mind. Even without online features, how could it not? As of iOS 26, the UI is composed of elements glowing, throbbing, jiggling, wiggling, and refracting. This is called "Liquid Glass".

But throughout a day, I might time my stretches, set a cooking timer, change my sleep alarm, turn on background noises, navigate with a map, or take a note. These can all be accomplished without "Going Online" if one can maintain perfect mental discipline in the face of a system adversarially designed to break your attention and get you to Go Online.

Note: At this point, I apologize if I am repeating text from Cal Newport's thinking on "Digital Minimalism". I feel that I am implicitly responding to people who have read his book, and I have probably absorbed many of the thoughts through osmosis and I am probably retreading much of the same ground. So, I searched "cal newport" "two phones" and the only results that came up were comments on his blog. Hooray!

Some advocates for minimalism wish to replace their phone with purpose-built devices. It conjures up the ludicrous image of someone heaving an overflowing pack. There is no minimalism in replacing one tiny device with the heft of a camera, a flashlight, a noise generator, a watch, a wallet, a level, a notepad, a world atlas, an emergency radio, a walkie talkie, a music player, a magnifying glass, etc. Need I go on? To me, this is clearly maximalist. We can achieve minimalism through technology with a bit of intentionality.

See, the iPhone 16 Pro is not my first smart phone! I have sadly broken every viable Android I've used (one by losing its password, another by trying to replace the battery, and a third by leaving it on the hood of my car during a camping trip.)

But I still own an iPhone 13 Mini which, save for its lack of a telephoto lens and dedicated camera button, I find to be a far more reasonably sized phone than anything on the market. Plus, it still runs iOS 18, which is a far superior experience compared to iOS 26. I have not connected it to the internet since 2024.

So, I maintain a second phone, for:

  • Ocean sounds and other background sounds
  • Clocks: Timers, stopwatches, and alarms
  • A compass and a level
  • Flashlight

(As a fun bonus, a second phone allows you to have two sources of background sounds, two sources of flashlight, or an off-camera source of light when taking photos, etc.)

In my day to day life, this has already been useful. I often read a book as I time my stretches, and I am reading with the same focus I had in my youth. I can walk along cliffs and throw off rocks and estimate their height using the stopwatch.

While not for the goal of digital minimalism, I have difficulty getting up in the morning, and a second physical alarm is useful for getting me out of bed.

I think I would like to periodically connect this second smartphone to the internet. If I were to connect this to the internet a few times a year, I think I would like to also use this phone for:

  • Obsidian, which I use frequently. I would set up a second vault, so as to avoid sync issues.
  • Maps, which can be used offline.
  • Photography. It is difficult to get photos off the device by wire, and Halide refuses to work unless I connect online.
  • Credit cards, which can be used offline, but have to be set up online.
  • Translations. (Apple has on-device offline translation, but one needs to be online to download the models.)
  • Maybe reading, such as a copy of Wikipedia, or e-books.

Discord is dying, Stoat looks like the replacement we need


TLDR:

  • Discord is already bad, but now it's going to require IDs and video selfies.
  • Stoat looks like the best. I think it is the ship to jump to.
    • Of the alternatives, all of them are either proprietary or use LLM-generated code, and a lot of the proprietary ones seem Evil.
    • If you are concerned about Stoat having had a few small LLM commits, know that Stoat is the most anti-AI alternative.
  • The Stoat LLM controversy is blown out of the water, since (1) Stoat has a very rare anti-AI policy, and (2) almost everything else has AI in it now anyways. You are definitely using software with LLM-generated code in it, directly and indirectly.

This article goes over the criteria for an alternative, why TeamSpeak, Mumble, etc. aren't up to par, and why the "LLM controversy" about Stoat is ill-informed.

In a few weeks, it will be March, and Discord will require every user to upload their ID or a video-selfie (The Verge), the latter of which will be analyzed using AI, and both of which will be sent to a third party vendor, only months after one of those vendors suffered a data breach.

This is on top of Discord having a mandatory arbitration clause and class action waiver which prevents you from being able to sue them in court (and, yes, this works in the United States), and this is on top of Discord scanning all your messages to train its AI models.

Discord has been bad for years and is getting worse, it's time to jump ship. I've been gaming on The Computer for years, and I've used IRC, Skype, Steam chat, TeamSpeak, Mumble, Ventrilo, and integrated game chats in everything from huge games like RuneScape to tiny long-defunct games like Goomba Online or Halo Crusades. I'm also a cybersecurity person, software engineer, and deep learning researcher who left in 2022 as I started to sour on the industry.

Having had looked at the alternatives, I believe Stoat is the ship to jump to. But it is facing some backlash over having had a few small LLM commits, which I believe is disproportionate.

A good alternative should be:

  1. User friendly. It should be easy for someone to start using this software on MacOS, Linux, Windows, Android, iOS, or in the web app. This is a minimum.

  2. Open source, both so we can jump ship if things turn to shit, but also so we can look at the code. This is increasingly important in an era of vibe-coded. You can assume anything proprietary is vibe coded.

  3. Not vibe coded. There's a difference between code that was created in part using LLMs, and someone lazily asking a chatbot to change a feature. Lots of bad software is being made by vibe coding, and some of them are crazy people who believe vibe-coding is a way to birth God. That's, uh,

  4. LLM guidelines that emphasize transparency and quality. As I'll argue later, LLM generated code is everywhere now. There is no way to discern LLM generated code from human generated code, and the only option is to hold code to a high standard in review. A contribution policy can never ban LLM generated code, it can only ban people from disclosing when they use LLM generated code. In the interest of quality and transparency, Forgejo's AI Agreement is a reasonable one.

  5. Privacy friendly. What's far far worse than having LLM generated code is having a privacy policy that sends all your messages to an AI model. You should rather take a privacy-friendly vibe-coded app with code you can inspect, versus something like TeamSpeak, which is proprietary and sends your data to train Grok

  6. No mandatory arbitration clause: This is a huge thing. It's increasingly common to include a section in the Terms of Service which requires users to agree never to sue the company. In the United States, these are almost always upheld, even in extreme cases.

Read more  ↩︎

Zed is easy to build which makes me happy

tldr: I have very low trust in Microsoft and their products. I am in the market for a GUI code editor to recommend and use in lieu of VS Code. I've used Atom, KATE, Lapce, VS Code, and VS Codium.

At a minimum, I want something that is open source and easy to build. Zed was annoying to build on MacOS because of Xcode, but Zed was effortless to build on Linux! This makes me think Zed would be less likely to be able to do a successful rugpull. (Plus, Zed does not have the same market position as Microsoft).

Zed is familiar and good and it's easy to disable all the AI features with one toggle.

As a note: This is one of the things I really love about Rust. The only painful thing about the build was that it took awhile to bake. But I had no debugging steps or effort to do when building Zed (on Linux).

Read more  ↩︎

Looking back on a differently productive 2025

In my post for 2024, I took sum of a number of accomplishments and things I created. But this 2025, I produced less software. What gives?

Read more  ↩︎