Reading the current password from memory = keylogger, I'm not worried about that. Reading every password I have or have ever had, including (I assume) encrypted notes and such? = keylogger on steroids.
But passwords aren't just about you, they're about the server they're also stored on too. Without a password manager, how do you propose remembering unique fully random passwords for dozens to hundreds of services over the course of decades? And they must still be easy enough to enter that most people will actually use it. And also be trivial to change at will, for when (not if) the password database is compromised. And in fact you directly bring up the problem of that being worse for services you use extremely infrequently. So if you use it frequently the keylogger gains it anyway, and if you don't use it frequently then what's your usable system again? Also, are not the most important things you want taken the least also the ones that tend to be used the most frequently? And with access to your email and in fact all communication services used on that system you don't see how an attacker wouldn't just be able to "I forgot my password" for many if not most services?
>Reading the current password from memory = keylogger, I'm not worried about that.
You're not worried about your system being rooted? I'd say you have an awfully different set of priorities when it comes to security then most of the world even beyond HN.
not fully random, but:
make up an algorithm that uses pieces of data that you know you can derive from some superficialities of anything you need a password for plus some some obfuscation function and some other data that you can derive or remember that is not related to the thing you need a password for.
e.g: the name of the site and the month you signed up in leet speek, rot-5'd and alternating letters, interspersed with symbols at some period related to a rhythm you like.
doing this gives you relatively strong passwords that you can reliably recreate while not needing to memorize them, that do not have an obvious pattern to them even if looking at them in mass, that have a very low chance of collision. you can remember a fairly complex recipe pretty easily ;)
depending on where your passwords are and what they're for, this might be preferable than storing them in one app that can compromise every password you have.
either way, someone only needs your important pw once. use multi-auth.
 I'm not sure what they're called exactly, but basically all you do is enter a password and it generates your password using your password + site + KDF.
there are plenty of things that this isn't an appropriate approach for, and fwiw I wouldn't tell someone it would be a good strategy for all their passwords.
it can be useful when you have a set of longer lived passwords that you need to care about guaranteeing that the entire set can't be snarfed without holding you at gunpoint.
there's a point somewhere a bit faster than monthly-expiration where I would consider using a store and random gen in situations where i would otherwise not. really depends on you, what it's for, and what risks you need to care about the most.
I don’t login to my online banking from my computer very often, nor do I login to government / tax services frequently. I’d be pretty upset if the credentials for these things (especially in the case of some banks, the second password required to perform any kind of transfer operation) got compromised simply because my entire password database got dumped from machine memory without having been used.
Security is a battle of convenience. If your threat model is state actors, then it may well be worth the inconvenience to have your data secured in several different locations, running Tails OS on everything, scrapping your smartphone, and so on.
Totally leaving aside the argument you were in - multiple single points of failure are bad, and very different than the opposite of a single point of failure.
Having a SPOF means one thing will take you down. Having multiple SPOF means any one of those can take you down. Lack of any SPOF means no one thing will take you down, it will require multiple problems. 3 distinct options.
Edit: hm, too much time elapsed for me to edit the parent post
This of cause doesn't help against a resourceful and highly targeted attack, but that's less of a concern for me than some malware toolbox adding support for common password managers.
You can't reset my online banking operation password by email.
You can't reset my crypto wallet passwords by email.
If you can read all of these from memory without me ever having interacted with the password, you can take all my money and then what do I do?
Malware that exists purely transiently in my system is a lot more likely to be successful and remain undetected, than malware that persists.
Even if an adversary has access to a machine, there is a difference if they can choose when/where to exploit/steal something, or if they have to wait for an action. If the adversary cant get persistence, a simple reboot of the machine might get them evicted and the keylogger is gone. That's just a simple example but it shows that things are more nuanced.
Apple for instance has efforts so that even root can't just debug arbitrary processes or unlock keychains of other users without them agreeing to it or disabling SIP.
It's about raising the bar and removing degrees of freedom for an adversary, so it becomes more dfficult. In the end of course systems can always be exploitable (given enough resources are allocated in breaking in).
Locks requiring more than 30 minutes are considered pretty much unbreakable (easier to break through the nearest wall).
This actually happened to someone at my company. But their passwords weren't compromised. If they were, I can't even imagine, the guys who took the machine were really trying to do whatever they could to ruin him and the company.
You make it sound like there's no mitigation at all for a password being compromised which isn't the case in practice.
If this ever happens, best plan would probably be to change your email password immediately, banks next, and freeze your credit as soon as possible.
But if it's ever breached I have no idea how you would get clear.
Ill also add that mitigating stuff like this was an early, easy use of separation kernels. They put the secret-protecting components, like disk encryption and VPN, in dedicated partitions outside Linux VMs. That worked well.
this is basically soft marketing of the skills they bring to the table. realistic/practical threat modeling not being one of them.
The high value things (bank, email, web hosting accounts) all have 2FA enabled.
The lower value ones, I can easily recover from a breach by simply resetting the PW via my email.
The only real threat I see is if you're storing passwords to things like encrypted containers (Veracrypt, TrueCrypt etc) but as you pointed out if they'd had something running on your system you're hosed either way.
My recovery codes are on index cards in a physical safe, and then I've got MFA via multiple devices (TOTP on Phone + yubikey for most things).
Or do you think that having both DBs on the same (possibly compromised) machine is too much risk?
Interesting idea. I had just been picturing a second keepass db with a different passphrase (or use a usb key with a keyfile kept offsite) but I like yours too.
(I'm also trying to brainstorm solutions scalable to non-experts so "&Ok fire up the CLI, we're doing GPG*" might work for me, but not everyone in my org :) )
I haven't found anything that I can self-host and allows me to have multiple "vaults". And I refuse to keep all my 2FA codes and recovery codes in the same place as the passwords, since that completely defeats the point.
When I asked 1Password about it, their response was that the functionality wouldn't be coming back in 7 because it wasn't a supported configuration -- it's called 1Password so users should only ever be remembering one password!
If Keepass's entire UX wasn't hot garbage it would be perfect. But here we are.
It can do this, and I don't see anything remotely resembling "hot garbage" in its UX.
That said, based on this report, the security model is significantly better, so the decision becomes do I care more about usability/being pretty, or security.
The never-ending trade-of between security and usability continues...
I'm not familiar with 1Password. How do you access these various "vaults" - you type a password, correct?
I guess I'm not following why multiple Keypass DBs with multiple passphrases is not acceptable for you, but several passwords in one app is?
(To be clear, I'm not saying your opinion is wrong I just want to understand - usable security is an interest of mine :) )
What functionality has gone from 7 and isn't coming back? Multiple vaults with distinct master passwords and not requiring their cloud backing?
You can set up multiple vaults, but it seems to store the master password for the additional vaults within the first, after the first time you unlock the additional vaults. So, effectively, it's a single vault -- access to the one gets you access to all.
The "mobile-passwords" git repo doesn't have any password I don't use on my phone.
Probably not a common scenario right now, but if this threat goes unfixed for a long time and tools become available to automate the attack I could see it becoming a problem.
That's what full disk encryption and (eventually) hardware security chips and the like are for. It's not a threat model that has anything to do with password managers.
>Probably not a common scenario right now
It never can be, that's the point. Physical attacks simply do not scale like purely online attacks do, let alone attacks on centralized single points (ie., a central password database).
>but if this threat goes unfixed for a long time and tools become available to automate the attack I could see it becoming a problem.
What? What tools "automate" stealing your notebook?? And also breaking through whatever physical security it has, like TPM or Apple's T-series chips or even just plain soldered on storage/memory/everything? The latter make repairs more of a PITA but they also make physical attacks significantly more difficult, even stuff like cooling memory and swapping (and encrypted memory based around tamper resistant security chips is a potential thing too).
That only helps if you assume the laptop is fully powered off when it is stolen. If it's on or merely in "sleep" mode, disk encryption doesn't help.
> It never can be
What can never be? Laptops being stolen? A threat doesn't necessarily need to scale to be a problem as long as the gain from individual compromises is sufficient to make it worthwhile.
> What tools "automate" stealing your notebook?
The stealing doesn't need to be automated, just the attack on the password manager itself. A program anyone can download and run on a stolen laptop to extract the password database would be sufficient.
First, I said FDE and hardware security chips like Apple's T2 and mentioned stuff being soldered on and HSM backed encrypted memory. Yes, simple FDE and standard PCs can be subject to physical memory swaps and the like, but that becomes vastly more complicated and difficult with devices that use significant hardware security. This is no different then a modern iPhone, where merely having physical possession, even with the phone not powered off, doesn't mean it's trivial to access the data.
Second, you're engaging in the security fallacy of inventing theoretical attacks without considering economic cost or whether they pass the weakest point test in the threat model. The sort of scenario you've come up with is not that simple and not the sort of thing some random crook is likely to do, which is how this thread was started. But if you're dealing with a targeted physical attack by an actor with significant expertise and resources, there are far more trivial weaker points to go for. For example, they could just stick a pinhole camera looking down at your desk (or anywhere else you frequent with your notebook) and just record your password and avoid the whole mess. None of this has anything to do with password managers.
>What can never be?
Try reading the conversation? I responded to "Probably not a common scenario right now", which implies that it could someday become a common scenario. Ie., an attack that could be scalable. But physical end point attacks are inherently not scalable, just like anything else that requires actual boots on the ground. Resource cost is the framework of all security.
>The stealing doesn't need to be automated, just the attack on the password manager itself. A program anyone can download and run on a stolen laptop to extract the password database would be sufficient.
If the stealing isn't automated then it's not scalable and it's an entirely different scenario. And this makes zero sense anyway. You can't just download and run anything on a stolen quality notebook without breaking it's physical security first, which is increasingly non-trivial. The password manager database has absolutely nothing to do with any of this.
All it takes is for the _exploit_ to be automated (not the actual act of stealing laptops) such that any random person off the street can do it. Then a targeted attack is no longer necessary; crimes of opportunity become the larger threat.
Is this true for Filevault? I know a lot of Mac owners who assume otherwise.
It's not just Mac users, I mentioned this issue in a meeting with an Apple sales engineer last month and he acted like you don't need to turn off a Mac to make it safer (he's not a security engineer so I don't really expect him to know how un/safe a running system with FileVault is). It may well be that the current OS and/or T2 chip makes it very, very hard to access the boot volume of a running Mac without a user's login but there's still a network exploit risk.
DMA access does sound plausible, but how can someone run a remote network traffic attack?
(I personally turned off any "smart wake" type of functionality)
If you have disk encryption you probably also have sleep mode lock the computer. So they still don't have access.
Not the parent but I assume they meant a tool that traditional laptop thieves with little technical sophistication can use to easily extract valuable data from a machine after they have stolen it.
I think the more obvious path is that if you have memory access, just wait for the decrypted contents to be exposed.
Basically even pretty good 2FA systems aren't at all full defenses if an attacker has root. They can help in very important ways to minimize the potential damage, to make recovery easier (since private keys are never compromised), to aid discovery/auditing, etc. But it's hard to avoid there having to be some trust in the client at the end of the day. And it's often a lot better to decentralize trust into client devices rather then something that can be centrally compromised. It's much harder for attackers.
Password Managers are no different, their raison d'etre is essentially trying to move the trust foundation more to clients. Client trust is a req though and any "compromise" that depends on controlling the client is uninteresting. They're basically a hack recreating PKI badly, but in a world where the technical foundations for a proper one didn't develop it's a good bandaid.
I always liked this idea: https://krypt.co/
Basically using an entirely separate device to authorize your access. 2FA devices still connect to the computer requesting access, I liked the idea that your phone act as the gatekeeper without ever touching your computer.
Problem is: It's a phone. Apple has done much but I wouldn't trust it either.
This is the point for 99.9% of people. If you're at risk of having someone attack you and your digital life in a targeted way, perhaps consider evaluating the security implications of each password manager.
Otherwise, pick any damn password manager and focus on something else.
People make the same mistake at the gym. "Which workout plan should I use?"
Any plan. Any of them.
Absolutely! For me, choices narrowed down to needing something cloud portable, 2FA, not needed another service like Dropbox just to access it, IOS integration, easy to share passwords with auto-update and revocation. But yea... just use something!
What do you think about it, just want to understand your perspective nothing else.
Yes i use a password manager.
As someone in that thread pointed out, I would say that the onus should be on the OS SDK to provide memory management primitives specifically for the purpose of security that can be zeroed out after use.
They also point out that the threat profile is someone who can read your system memory when 1P is locked (serious compromise already), but is unable to read it when it's unlocked (otherwise why bother reading it when locked), which is a pretty small set of use cases.
I can think of at least one situation where that would be the threat profile: someone steals your laptop.
Not a super common scenario, but not exactly unheard of either.
1- User uses the laptop and logs into 1P successfully then locks it.
2- Hacker steals the laptop and uses it without a reboot.
3- Hacker hacks the windows/mac os password to logon.
4- Hacker dumps process memory for 1P.
For me, they would have to steal it while I'm actively using it. When I go away from my desk, I enable the screensaver which A) requires my Mac login password to unlock and B) locks 1Password, requiring the master password to unlock.
In 1Password 6, the Prefrences > Security settings include Auto-lock: on sleep, when screen saver is activated, when main window is closed, when fast user switching, when computer is idle for X minutes. I use all but "when main window is closed." It's much less of a nuisance since I started using Touch ID to unlock 1Password.
I haven't looked into them in a while but there is 3rd party software than can automatically enable a system's screen saver when a particular Bluetooth device is out of range (e.g. a smartphone, a smartwatch, etc.) which would help even more.
From a Washington Post article on this study: "LastPass had me speak with its top technical executive -- but it also got [lead researcher] Bednarek banned on Bugcrowd, the site for researchers to report flaws, because he disclosed the bug to me."
More from CyberScoop:
The other findings about sensitive information remaining in memory even _after_ the password managers are locked are concerning however. It'd be great if the article included a link to the CVEs or bug tracker issues for these vulnerabilities so we could keep track of whether or not they've been fixed.
Sounds like a reasonable countermeasure is to quit the manager when not in use.
After all, I'd need to enter my password if I was "unlocking" or restarting the app either way. (At least in my manager)
If you can read local memory, you can probably write to (at least other) memory, and then it's a short hop to content injection and session hijacking. Erasing key material from memory or preventing its misuse then only seems useful against cold boot attacks.
It stays encrypted at rest on your machine protected by GPG keys and when you want to access a password you can choose to copy it to your clipboard for 45 seconds or print it to stdout.
No subscription services, and everything stays local on your machine, but you can easily sync it to other devices using whatever file syncing service you want since it's just encrypted files on disk.
But you have to ask yourself. Who are you protecting against here? Are people browsing around your laptop / workstation without you monitoring what they're doing?
If someone has your machine without your consent, then you're pretty much screwed because 99.99999% of people will leave themselves logged into things like gmail which requires no password to access it once the machine is powered on. It's basically this xkcd scenario: https://xkcd.com/1200/
Nope - but the industry that I work in constantly assumes "bad actors" are present. Although it's not perfect - everything is 2FA, all disks on laptops encrypted, there are strict rules in dealing with secrets/sensitive information, etc. My main concern is if someone were able to do a rip of my home directory.
Trust me - there's a TON of room for improvement, but doing some general protection against someone with "shell" access is something I'm in the practice of... it's the same reason I carefully manage what ends up in my .zsh_history or .bash_history =)
> If someone has your machine without your consent, then you're pretty much screwed
Agreed. Encrypt the disk (I trust LUKS), lock your machine when not in-use, ensure it shuts itself down if a password is "fat-fingered" more than twice, use solid passwords with good complexity, use 2FA when you can/should, etc.
Will be looking into this to replace a KeePass DB!
Then you can choose to either type it in every time you unlock a password or cache it for your session (depends on how important security is for you).
Personally I cache it for my session. This way I only need to type in my pass phrase once when I power on the machine.
The best part about the pass utility is that it piggy backs off GPG for its encryption mechanism.
A quick Google shows this: https://github.com/drduh/YubiKey-Guide
I didn't read everything but it seems pretty comprehensive.
This actually accomplishes a few things:
* The keyfile is safe from processes launched using the standard user account (i.e. non-elevated). Malware accidentally launched by 'me' can't read it.
* Keepass.exe is running in the admin process space, which protects its memory from processes running in non-elevated space.
* Launching admin-space Keepass, and seeing the UAC prompt, Microsoft includes information about how the exe is signed -- which Keepass is -- that allows me to verify every time that I'm not launching a bogus keepass.exe.
* The password database file is still in user-land, so it can be synced with standard cloud sync tools. It is worthless without the keyfile though, even if my master pass ever slipped.
> Surprisingly, we found that it is less secure in the running state compared to 1Password4. 1Password7 decrypted all individual passwords in our test database as soon as it is unlocked and caches them in memory, unlike 1Password4 which kept only one entry at a time in memory. Compounding this, we found that 1Password7 scrubs neither the individual passwords, the master password, nor the secret key (an extra field introduced in 1Password6 that combines with the master password to derive the encryption key) from memory when transitioning from unlocked to locked.
That is unacceptable, what type of developers do they have?
I don't imagine anything will come from it for a while however.
Native is often riddled with bugs and the threat model of reading the data out of memory is basically irrelevant.
> During a workflow to derive the decryption key, the master password is leaked into a string buffer in memory and never scrubbed, even when LastPass is placed into a locked state.
Altogether I’ve moved 100 people to LastPass and some of those users have been not-exactly-power-users, yet, zero complaints from 100 people. A year later almost every single one is still using and the downstream effect of children/friends/kids is surely in the hundreds. They owe me a shirt or something really!
LastPass isn’t perfect but it’s pretty great for the price. What made you switch to 1P v7?
I have to use both LastPass (enterprise) and 1Password 7 (personal). The experience is pretty incomparable: the LastPass user interface and browser extension are abysmal, whereas 1Password is very enjoyable. On the most recent version of Chrome, the LastPass extension is slower, less intuitive and less organized than the 1Password extension. 1Password also has more features and a fast desktop application for macOS.
Note that I'm not saying LastPass doesn't work. It works...but it's an incredible pain for me to use every day at work after using 1Password at home. I think the design sucks, to put it bluntly.
I've had none of the UI issues you have (Firefox, Safari) and have heard none from any user. Weird!
I had to use LastPass at work, maybe 2 years ago, and I can confirm, it may have had the worst user interface (both in terms of aesthetics and usability) of any webpage I've ever had to use. I simply couldn't believe any self-respecting developer shipped that.
I'm probably done renewing. I've been using keepassx for things like banking and trying out bitwarden for the less consequential stuff.
Sorry - this turned into a rant.
> Using CryptProtectMemory and CryptUnprotectMemory for password encryption is not secure because the data exists as plaintext in memory before it is encrypted and at any time the caller decrypts it for use.
In order to benefit from CryptProtectMemory you have to carefully lifecycle strings in and out of secure storage as needed; this wouldn't mitigate some of the issues presented in the article.
These are effective against non-specialized attack software.
If you work for the NSA and cover yourself with a tinfoil blanket to enter your passwords, just lock and close the password manager completely after you've used it to login to a service, and you're all good.
Basically we are one browser exploit away from using ad-networks to steal all your passwords (from 1Password7).
Ok, so say the malware couldn't access all your passwords immediately. It's just going to sit on your computer and collect them (and existing sessions) as you use them, or force you to re-auth and then collect them. And if it's highly prized info, the malware will eventually get updated with a privesc to go around the user context. This is what malware has been doing for years, and nobody notices until exfiltrated passwords start getting used.
Another way to go would be tiers of password managers. Even if all of their unlocked integrity sucks, you can have one manager that keeps your most sensitive accounts, and another manager for the rest. You rarely unlock the sensitive one, and after you log in, you unlock it and exit it. Now you have much better opsec with very little additional cost.
If only recently accessed passwords were unencrypted, only those would be available.
Keep using a password manager. Write down your 2FA codes separate in a safe place. (I recommend everyone own a safe deposit box)
For ages, on Unix this could be solved with users and daemonisation. Later came SELinux which is criminally underused.
In the popular OS market, for a while there was flocker, on OSX. It used event hooks in the kernel to allow fine grained control over filesystem access, locking certain dirs down to certain apps. The app was bought by some enterprise offering (f-secure) and taken offline. The creator (Jonathan Zdziarski) was then hired by Apple. Recently, similar features have been rolled out by Apple natively for OSX. Try reading your iMail or calendar cache using the terminal: you’ll get an iOS-like pop up window asking you if this app has permission to your mail, or contacts. This is a step in the right direction.
All that’s left is for Apple to allow the user (or app developers) to specify such locks ourselves. This was already possible with flocker, but unfortunately that’s nowhere to be found, anymore. Perhaps it’s possible for apps delivered through the App Store? This would solve the problem that a password manager offers any process access to your full (encrypted) password DB, which is a pretty serious problem (makes the master password too valuable!).
Given the direction things are moving in, and the hire of Jonathan, I’m very hopeful this will eventually arrive. It would be a tremendous win for security on OSX. This everything-goes mentality of FS access has been a pet peeve of mine for over a decade. :) and, tbh, I think it’s a much more relevant attack vector than some process “reading memory”.
Nowadays, a password manager can't even do that?
* might not be straightforward as it install some DLL inject stuff
Is this a mistake or am I missing something?
That phrase doesn't really capture what iterations means there. How you said it makes it sound like you only have to try 100k computations to brute force a valid answer, which is certainly not true.
It's talking about key stretching / key derivation .
That is not 100100 iterations to brute force it, that is 100100 iterations of PBKDF2-SHA256 applied to the password you type in as the master password.
It does look like the tables are not identical. However, since lastpass's docs  say it's 100100 (and configurable), I'd say that's likely the accurate default value.
But as pointed out above, if someone has access to dump your machine's memory then you've got bigger fish to fry.
Whaaat? I'm going to call citation needed here. Afaik there is not significant difference in the memory protection model between any of the mainstream OSes
I don't mind paying to buy a good tool but the Saas model is getting out of hand.
If i ever find the courage to run Docker in production, i will probably give it a try.
edit: there's the unfortunate fact that the names of files in which passwords are stored are in plaintext, since it's all ordinary files and directories. pass-tomb is supposed to be a good way of encrypting your .password-store directory, but I don't think this is compatible with the iOS app. Still, not a serious problem for my use case anyway, and a solution is available if I'd be willing to forego the iOS app.
Please note, I'm the owner of this project.
"The idea behind Authorizer is, to use old smartphones as a hardware password manager only. To avoid manual typing of long and complex passwords everytime you need them, Authorizer pretends to be an USB keyboard (e.g. over an USB On-The-Go adapter). With a button press inside the App, it will automatically enters the password for you on your pc, laptop, tablet or main smartphone."
edit: looks like AgileBits has already responded
I would assume that a pseudo-random moderately strong password per site stored in your brain would be more secure than a random strong password that's stored electronically and vulnerable to attack, but maybe not?
There's no such thing as perfect security, and IMO a good middle ground is memorizing a long, strong passphrase to unlock a password manager full of random PWs for individual sites.
I guess you could write them down instead, but personally I'm much more worried about someone stealing a physical notebook than getting malicious software onto my computer.
(For example, what happens when you cross a border and an enterprising young border officer photographs the contents of your passwords notebook? This would be perfectly legal in most countries.)
I would assume if that were the case they can intercept the password from the paste buffer anyways.
At any given time, the number of people who can attack your notebook is... maybe five. The number of people who can attack your computer at any given time is seven billion.
(Also, there are trivial things you can do to make a paper notebook even better. Write the passwords consistently slightly wrong, according to a rule that you only know in your head, or have a common part of all of your passwords only you know, and then use the notebook for uniqueness.)
Asking someone to brain more than 5 good passwords is entirely pointless. We just aren’t wired for that.
I’ll agree that secure paper is best for security, but not many people understand what “secure” is. A notebook on your desk isn’t, in a safe is. If I need to log in to AWS at the supermarket, that notebook does me no good.
I agree, what is "good enough" security depends on your threat model. For example, for an older adult who previously used one dictionary word on every site, a small notebook with a list of PWs in a locked desk drawer is a big step forward.
I like to tell people to treat passwords they have written down like they would a hundred dollar bill. (You keep it on your person, or lock it up when not in use).
Does that system fall apart if you need to securely and remotely share a password with your mom? Because that is the standard of usability I've been considering.
If it's not the government, isn't a phone call sufficient? Harder to tap, and presumably she knows your voice.
So I think it should be obvious when I say my mom, that's a user I have no control over, I can't yell at, I want to make sure there are no mistakes, and that she can't mess anything up on her end like writing it on a sticky note... If you haven't figured out, mom is the worst possible case for a user.
You're getting lost in the details. It should be SIMPLE to securely share credentials or codes or details with someone, and that can't be done if a piece of paper is your system.
The method has detractors who would argue that the word choice wouldn't be random enough, but that's because they employ a strawman who insists on either choosing their own words or using only words they are familiar with. If you actually pull words randomly from a really big dictionary, it has plenty of entropy. Having some obscure words in your passphrase only make it even more memorable anyway.
For unimportant things, like your HN account, who cares.
A lot of password advice today is bad. You only should be making valuable passwords (those that control sensitive data or access) unique. Forum accounts do not need that level of security and you waste cognitive power by doing so.
Banks, email accounts, and a handful of others are the only ones worth truly securing. And passphrases can be incredibly easy to remember, unlike passwords.
I have access on a forum where if I log out it asks shows me my sessions, including my IP address. My IP address is PII. I have my e-mail address hidden on this forum as well. My e-mail address is PII.
I have ordered something on AliExpress. My physical address can be found by logging in to my account. I actually have multiple addresses on my eBay account where some can save me some costs due to being in a different country.
And if anyone logs in to my account on AliExpress, they'd be able to log in on that other forum or eBay as well if it weren't for a password manager.
My password manager allows me to make a passphrase, btw. The terrible thing about a passphrase is it takes long to type it, and a typo takes even longer. I prefer a YubiKey plus a decent PIN though it doesn't work very well against a hostile government.
Though it's also in the platform's best interest to defend itself from weak passwords because there are usually a lot more defenses against fresh accounts than existing accounts that get taken over. We're seeing websites becoming more and more proactive here like rejecting passwords that appear on haveibeenpwned.
Also, I recognize your username from your extreme stance against password managers in the past and you seem to make the mistake of not acknowledging trade-offs. I think it weakens your point, especially when talking about end-user security where 90%+ of people are reusing passwords, not debating whether they should use a password manager or roll their own physical password pad scheme.
If you reject current password managers, can you envision a digital solution that would satisfy you?
You could also use one long passphrase for your password manager that even a state level adversary probably can't crack:
Edit: To be clear, one passphrase for your password manager not 1 passphrase used on every site.