# Are software password managers fundamentally trustworthy, or just "good enough"? **URL:** https://discuss.privacyguides.net/t/are-software-password-managers-fundamentally-trustworthy-or-just-good-enough/40290 **Category:** General **Created:** 2026-08-29T14:40:40Z **Posts:** 78 ## Post 1 by @s0k0l — 2026-08-29T14:40:40Z Been thinking about this for a while and wanted to hear how this community sees it. I use KeePassXC - encrypted database, strong master password, the works. But the more I think about the actual threat model, the less confident I feel. The database gets decrypted inside the OS, in RAM, right next to the browser and every other running process. If a machine gets hit with an infostealer, the attacker doesn’t need to crack anything - they get the master password and the decrypted database in one pass. And there’s no way to know it happened until your accounts start getting used. So software password managers solve one problem really well - using unique, strong passwords per site, which protects against credential stuffing when a database leaks somewhere. But they do nothing against a threat that’s arguably far more common in practice - malware on an already-unlocked system, which steals the master password and the entire database in one go. Genuinely curious what people here think: - Do you consider this a real gap, or am I overweighting infostealers as a threat? - Has anyone moved to keeping credentials off the PC entirely (hardware token, offline device, paper, etc.)? - If you were to design a “physical” password manager from scratch, what would it need to actually earn your trust? --- ## Post 2 by @TheDoc — 2026-08-29T15:33:17Z > [@s0k0l](#): > > So software password managers solve one problem really well - using unique, strong passwords per site, which protects against credential stuffing when a database leaks somewhere. But they do nothing against a threat that’s arguably far more common in practice - malware on an already-unlocked system, which steals the master password and the entire database in one go. Tools only serve specific purposes, overall security is always multifaceted. Knowing how to protect yourself from malware is as essential as choosing a good password manager. > [@s0k0l](#): > > - Has anyone moved to keeping credentials off the PC entirely (hardware token, offline device, paper, etc.)? This is where security keys (especially [YubiKeys](https://www.privacyguides.org/en/security-keys/#yubikey)) are very useful. An infostealer on your computer wouldn’t be able to access your passkey private keys or TOTP secrets, at worst they should only gain temporary access to your accounts. Anyone who can’t afford a security key could store secrets on their Android/iPhone instead of their PC as they’re usually much more secure against malware. --- ## Post 3 by @s0k0l — 2026-08-29T18:13:13Z Agreed, you’re right about security keys - they genuinely close that specific vector: passkey and TOTP secrets are physically isolated on the key, an infostealer can’t reach them. But here’s the nuance: that works great for authenticating into individual services. The question was about something different - the primary secret, the one key that unlocks everything else, which can’t really be moved to a YubiKey in the first place because there’s no standard for it. LUKS - just a password. PC root - just a password. The KeePassXC database itself - also just a password, because there’s nowhere to fit OTP. A crypto wallet seed phrase - no 2FA involved by design at all. And here’s the funny part: someone can easily have TOTP set up on a game store account, while having zero protection on their crypto seed phrase, which usually just sits as plain text somewhere on disk or in the same password database. We end up protecting the stuff that’s relatively low-stakes anyway, while leaving the actually valuable thing completely exposed. I’d also push back on phones being inherently safer. To me it all looks equally leaky, just a different attack surface. Moving secrets from a PC to a phone isn’t solving the problem, it’s just relocating it to wait there instead. And there’s the AI angle too - generative models are already capable of writing functional malicious code, and polymorphic, adaptive malware we haven’t even seen yet seems to be right around the corner. So betting on “this device is safer than that one” feels like a pretty shaky long-term strategy. --- ## Post 4 by @user1 — 2026-08-29T18:25:30Z Password managers are not a solution against malware, you are comparing oranges and apples. If your system is compromised there is no tool that is safe. If your threat model is malware you should consider other measures. --- ## Post 5 by @s0k0l — 2026-08-29T19:38:27Z Disagree. “If the system is compromised, nothing is safe” only holds when the secret lives on that system - like with a software manager. If the secret never lives on the PC at all, and only arrives as a finished password at the moment of entry, malware can catch that one password, not the whole database. --- ## Post 6 by @donutfreak — 2026-08-29T21:41:24Z There’s been advice to lock the password manager app between uses. For KeepassXC, that’d be a ctrl-l to do that for the desktop application (keys may vary between OS). To me, this is probably good, but adds a lot of friction if one has a difficult password to type or a really really long password (20+ chars or so), or frequently bounces between site logins. --- ## Post 7 by @winteranimal — 2026-08-30T00:46:40Z I don’t think software password managers make sense on monolithic desktop oses, which run everything in the same os image. I use keepassxc on qubes-os, where its in its own vm, and so is everything else. The relevant vm only ever sees the password pasted into it. Unfortunately Qubes uses X11 instead of wayland, so everything in that vm can see it. Browsers for specific contexts get their own vm to minimize that attack surface. The best I can think of is passkeys and keeping your password manager on your phone. Passkeys won’t save you if the os get compromised. Most mobile oses, including ios and android, are better about compartmentalization than monolithic desktop OSes. Graphene is good. --- ## Post 8 by @s0k0l — 2026-08-30T09:18:56Z @donutfreak on locking between uses - reasonable idea, but if the system is already infected with a keylogger, locking doesn’t actually help. The keylogger just waits for the next master password entry and catches it at the moment of unlock. So you get the friction without the actual protection. --- ## Post 9 by @s0k0l — 2026-08-30T09:19:42Z @winteranimal Qubes is a genuinely solid approach, VM-based process isolation does reduce the attack surface. But it comes with its own cost: entering the password becomes mentally harder, it goes through the clipboard, which KeePass can no longer reliably clear in an isolated VM. Plus you still need to back up the database in case you lose access to the working machine, and none of this removes the actual act of manually typing passwords (to even reach the database in Qubes, you need the disk password, the user password, and the database password itself - at least 3 complex, highest-stakes passwords still living in your head or on a sticky note, still getting typed by hand). What if a hardware password manager typed the passwords for you instead - via keyboard emulation, no clipboard involved at all? And worked the same way everywhere: Windows, Linux, Qubes, phone - no software, no VM setup, no tradeoff between convenience and isolation. Plug it in, use it. --- ## Post 10 by @TheDoc — 2026-08-30T13:54:54Z > [@s0k0l](#): > > The question was about something different - the primary secret, the one key that unlocks everything else, which can’t really be moved to a YubiKey in the first place because there’s no standard for it. LUKS - just a password. PC root - just a password. The KeePassXC database itself - also just a password, because there’s nowhere to fit OTP. There are ways to implement alternatives to passwords or something similar to 2FA in many of these scenarios. [KeePass](https://keepassxc.org/docs/#faq-yubikey-2fa), LUKS (either as “[2FA](https://forum.qubes-os.org/t/luks-with-yubikey-2fa-chal-resp-on-qubes-4-2-0/23119)” or an [alternative to passwods](https://fedoramagazine.org/use-systemd-cryptenroll-with-fido-u2f-or-tpm2-to-decrypt-your-disk/)), [Linux login](https://support.yubico.com/s/article/Ubuntu-Linux-login-guide-U2F), [QubesOS login](https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/mfa.html), etc can support this. In any case, if you’re still accessing sensitive data on a PC of course the PC needs to be secure. As I said earlier, this goes beyond the realm of login/decryption security and into the realm of protection against malware and exploitation. In the best case scenario, an advanced workflow with air-gapped devices could offer the most protection against malware. > [@s0k0l](#): > > I’d also push back on phones being inherently safer. To me it all looks equally leaky, just a different attack surface. Moving secrets from a PC to a phone isn’t solving the problem, it’s just relocating it to wait there instead. They’re not always the best option and some of them can have privacy footguns enabled by default, but mobile devices are generally [much more secure](https://madaidans-insecurities.github.io/security-privacy-advice.html) in the sense that they tend to have the best security features and exploit mitigations compared to PCs. Of course, security keys and air-gapped devices are even better but not everyone is willing or able to use those. --- ## Post 12 by @s0k0l — 2026-08-30T17:15:05Z One nuance: a LUKS password and a crypto wallet seed phrase can’t be protected by any alternative or 2FA layer, by design - there’s simply no slot for a second factor. So for those two specific cases, there’s no alternative at all.And even where alternatives technically exist (KeePass, Linux login) - none of them deliver the actual thing that matters: freedom from having to remember and manually type a password. You’re just swapping one password for another, or adding a step on top. The core fact - keep a secret in your head, type it by hand - never actually goes away. I agree with you on air-gapped devices being the best-case scenario - no argument there. The real question is something else: you said yourself that not everyone is willing or able to use them. I don’t think that’s a property of the air-gapped approach itself, it’s more a consequence of existing implementations (security keys, HSMs) being built around specific protocols and requiring service-side integration. What if an air-gapped device wasn’t tied to a specific auth protocol at all, and just handled the typing itself - emulating a keyboard, working anywhere, with zero support needed from the site or OS? Then the barrier to entry disappears, but the protection stays the same. --- ## Post 13 by @ProgrammAbel — 2026-08-31T02:24:34Z Some of your posts sound like they might be generated by an LLM, just want to note that this is against the guidelines --- ## Post 14 by @sha123 — 2026-08-31T07:05:34Z > [@s0k0l](#): > > But they do nothing against a threat that’s arguably far more common in practice - malware on an already-unlocked system, which steals the master password and the entire database in one go It’s not more common. Credential leaks from servers are much more common than info stealers on end-user devices. Which is also the reason why password managers are recommended. --- ## Post 18 by @Gersand — 2026-08-31T11:44:12Z I am not entirely sure it answers your specific use case, but here is what I do. My KeepassXC database remains closed and can only be opened with a Yubikey. I set autotype patterns for my various sign-in forms. I have a shortcut to trigger autotype. When I need to fill a sign-in form, I hit my shortcut and plug the Yubikey, which opens the database and allows me to enter the sign-in sequence (or manually copy-paste credentials). At this point, I confess I don’t know whether the master secret is exposed to an infostealer in my RAM. Then I close my database. > **Edit: additional info, I would love if someone has some insights to teach me.** > > My setup is actually a bit more complicated: > > - I have two databases: > - one that I open with the Yubikey, containing a single AutoOpen entry, which opens the second database; > - the second database with all my credentials, to be open with a very complex password > > - When I hit the shortcut, I insert my Yubikey, with opens both databases. > > I did this to be able to sync my database with my phone. On the laptop, I use the Yubikey; on the phone, I use the fingerprint. --- ## Post 19 by @not-wittingly — 2026-08-31T12:25:26Z They are the best solution currently available. --- ## Post 20 by @not-wittingly — 2026-08-31T12:29:01Z > [@s0k0l](#): > > a LUKS password and a crypto wallet seed phrase can’t be protected by any alternative or 2FA layer, by design - Though it’s a bit hacky, you could put the LUKS header onto a USB. Then you have a headless volume for which you need the password (know) and the USB (have). So you can get 2FA like that, though I conceded it’s convoluted. --- ## Post 21 by @s0k0l — 2026-08-31T12:29:45Z So, besides spying on the master key, there are also ways to attack memory, since the program has nowhere else to store the decrypted database. --- ## Post 22 by @s0k0l — 2026-08-31T12:37:56Z Even if you take the header out separately and remove it from the partition, you still have to deal with the bootloader, and it can’t be encrypted by design, otherwise the system won’t know where to boot from. So the bootloader is always exposed, and it can be modified. And most importantly - this still doesn’t solve the original problem. You still have to come up with, remember, and type a password by hand every time. --- ## Post 23 by @Gersand — 2026-08-31T12:45:03Z I count on the fact that the database is decrypted during a short while. I don’t know about RAM scanners and how automated they can be, or how often then may take snapshots, so maybe I shouldn’t count on that. And do you know if the master password is stored in plaintext in that setting ? --- ## Post 24 by @s0k0l — 2026-08-31T13:11:32Z No, the master password is never stored in plaintext. Only by mistake. And there are only 2 attack vectors: grab the password from the unlock form field with a keylogger, or take a RAM snapshot after unlocking. The attacker doesn’t need to constantly take memory snapshots and search for the KeePass database there. It’s enough for them to watch focused window names. Do you still type any passwords at all? Or is what you described everything? --- ## Post 25 by @Gersand — 2026-08-31T13:53:02Z I never type passwords. But now and then, I copy-paste them from KeePassXC’s database. --- ## Post 26 by @s0k0l — 2026-08-31T15:18:50Z Good, are you don’t have luks encryption and auto login enabled? --- ## Post 27 by @Gersand — 2026-08-31T15:43:43Z have LUKS for my root partition and my boot partition, with the same key file, that automatically opens at boot time. I have a Veracrypt volume with a key file that automatically opens with a systemd job at multi-user.target. I don’t have autologin. --- ## Post 28 by @s0k0l — 2026-08-31T16:33:17Z That’s a great setup. I configured something similar with Linux Mint. Kind of a bummer that if anything breaks, you have to set it all up again from scratch. --- ## Post 29 by @s0k0l — 2026-08-31T16:48:33Z And what are you think about a harware password manager? --- ## Post 30 by @Gersand — 2026-09-01T10:35:55Z I didn’t know it existed. Right now, I struggle to see the point, but maybe you or someone has insights ? Actually, doing some research just now, I see autotype seems less secure than copy-pasting passwords, at least for KeepassXC since it uses XWayland, where keyboard events can be seen by any application in the background. The remaining attack surface with copy-paste remains the clipboard. I don’t know how hardware password managers handle the passing over of the passwords. --- ## Post 31 by @s0k0l — 2026-09-01T15:37:19Z There are actually several reasons to get the valuable stuff out of a burning house - the PC, in this case. First, it protects the valuable data itself. Second, it lets you use it interactively anywhere - log into a friend’s computer, connect a TV to WiFi, that kind of thing. Third, it works everywhere with zero setup. Fourth, it’s basically a pocket cloud. --- ## Post 32 by @Libre_Software_Enjoyer — 2026-09-01T18:02:48Z > [@s0k0l](#): > > The database gets decrypted inside the OS, in RAM, right next to the browser and every other running process. If a machine gets hit with an infostealer, the attacker doesn’t need to crack anything - they get the master password and the decrypted database in one pass. And there’s no way to know it happened until your accounts start getting used. Therefore you should only install trusted software and install everything else in a sandbox, like Flatpak. > [@s0k0l](#): > > - Has anyone moved to keeping credentials off the PC entirely (hardware token, offline device, paper, etc.)? I am keeping some credentials only on my phone (GrapheneOS), since its far less likely to get hacked. --- ## Post 33 by @s0k0l — 2026-09-01T18:31:37Z Here’s the thing - what you described, moving your most sensitive credentials to a separate device (GrapheneOS) that isn’t used for everyday browsing and doesn’t carry the same attack surface as your main PC, is basically the idea of a hardware password manager. You’re just using an entire phone to do it, because there wasn’t a purpose-built solution available. And still, it’s Android - it can’t type the password for you, you’d have to retype it by hand. A phone, even with GrapheneOS, is still a phone and will behave like one, while a purpose-built device can be programmed to do whatever you need. A hardware password manager would get rid of that need entirely. Do you think a purpose-built device for this could actually make your life easier, or are you fully happy with the phone setup as it is? --- ## Post 34 by @Libre_Software_Enjoyer — 2026-09-01T18:37:51Z > [@s0k0l](#): > > And still, it’s Android - it can’t type the password for you, you’d have to retype it by hand. I can copy from KeePassDX on and then past it into the credential field of whatever service I want to use. > [@s0k0l](#): > > Do you think a purpose-built device for this could actually make your life easier, or are you fully happy with the phone setup as it is I think max security devides have some merit. For example hardware wallets that can handle crypto transactions, U2F and FIDO are very beneficial --- ## Post 35 by @Gersand — 2026-09-01T20:08:02Z > [@Libre_Software_Enjoyer](#): > > I can copy from KeePassDX on and then past it into the credential field of whatever service I want to use. Have you checked KeepassDX magic keyboard feature ? You don’t even need to copy-paste… --- ## Post 36 by @Gersand — 2026-09-01T20:26:41Z > [@s0k0l](#): > > There are actually several reasons to get the valuable stuff out of a burning house - the PC, in this case. I have a Nextcloud instance synchronising several devices, for this. > [@s0k0l](#): > > First, it protects the valuable data itself. Second, it lets you use it interactively anywhere - log into a friend’s computer, connect a TV to WiFi, that kind of thing. I have never been in those situations, and don’t plan to be in a foreseeable future. > [@s0k0l](#): > > Third, it works everywhere with zero setup. Fourth, it’s basically a pocket cloud. I think there definitely are use cases for this, such as managing a computer fleet or some server room, or if you repair clients’ computers. But it’s not my case. I think there are some things to keep in mind, though: - Don’t forget to have 2 such devices, because one may break or stay in the burning house. - How secure is the embedded software/driver passing the passwords to your apps? --- ## Post 37 by @foolclown — 2026-09-01T23:18:35Z In terms of OS/boot security, what’s your guys’ opinion on TPM 2.0? I have an option to set this up in my Linux distro, right now I just use a simple LUKS password, which is… not ideal --- ## Post 38 by @Bumbashirovich — 2026-09-02T02:14:46Z I have TPM 2.0 enabled, but the PIN code is not activated. I rely entirely on my BIOS and LUKS passwords. I don’t understand why I need complicated settings. --- ## Post 39 by @s0k0l — 2026-09-02T07:46:08Z > [@Gersand](#): > > I have a Nextcloud instance synchronising several devices, for this. Nextcloud isn’t really “getting passwords off the PC” though - it’s “duplicating the secret data in one more place” and “making your secrets reachable over the network 24/7.” And it raises its own question: where do you store the credentials for the cloud connection itself?Backups are always needed, that’s a separate concern - and that’s exactly what you set up Nextcloud for, which makes sense. But it’s not an alternative to getting secrets off the PC, it’s just backup redundancy layered on top of whatever solution you’re using. And there’s another important point: if the setup breaks - the keyfile USB fails, the YubiKey dies, or the hard drive itself goes - there has to be a fallback to a plain password everywhere. Which means those passwords need to physically exist somewhere, along with the Nextcloud credentials, because if the hard drive fails, the KeePass database becomes completely unreachable. So you’re required to have offline backups of your access credentials - on a USB drive, for instance. --- ## Post 40 by @s0k0l — 2026-09-02T07:46:57Z A hardware password manager, as I currently picture it, won’t protect against a keylogger - the base version uses USB-HID emulation, and that’s an honest limitation. But it does three other things that software solutions handle far worse: First, it physically isolates the entire database from anything running inside the OS. Second, it gives you maximum protection instantly, with zero configuration, because it handles password generation, storage, and keyboard input all in one. Third, it gives you the convenience of a cloud solution - access from anywhere - without creating the attack vectors that come with actual cloud solutions. There are plenty of reasons for a hardware approach, and they’re not just about today. Computers become obsolete, technology moves on, one encryption scheme replaces another, one company replaces another. What’s relevant today might not even run in a couple of years. AI is advancing and already enabling better cracking tools. And people genuinely need a hardware solution - I see it in the fact that plain paper password notebooks are still selling well on Amazon. The fact that you configured your system for passwordless access proves it’s possible. But the fact that it’s just been me, you, and maybe two and a half other people doing it says the setup is extremely exotic. Everyone else picks one of two options: give up on passwords entirely, or type one even at the BIOS level. One thing’s reassuring though - you and I both agree passwords are tedious and should be automated. I’m with you on that: people shouldn’t have to think about passwords. --- ## Post 41 by @s0k0l — 2026-09-02T08:00:04Z Never used TPM myself, only heard about some vulnerabilities in the module. Personally, I don’t see much point in storing encryption keys on the same hardware you’re trying to protect - a password is no worse than a keyfile in that regard. The only real difference is that a password has to be typed by hand, and that’s exactly where all these compromises come from - the tradeoff between convenience and security, between autologin and typing manually at every step. --- ## Post 42 by @s0k0l — 2026-09-02T08:28:27Z That’s exactly it, it’s right in line with what I’ve been saying. Why go through a complicated, time-consuming setup when you could just type a password? But you can’t hold a complex password in your head, and when you’re dealing with multiple systems, it only gets harder. On top of that, passwords need to be rotated regularly. There’s a mismatch here, I think: we have unbreakable encryption algorithms, but the responsibility for the password - the single most important part of the whole chain - gets handed off to whoever happens to be operating the system, regardless of whether they understand any of this. A hardware solution would take that burden off the user entirely. Looking at the direction things are heading, all I see is more and more second-factor tools. A YubiKey is also a 2FA device, not a “does everything for you” device. To use it, the system it’s plugged into still needs to be configured. LUKS, and especially keyfile-based unlocking, doesn’t free you from passwords either - and it demands a fairly high skill level from the operator. Passwordless auth is being developed right now, but just like software password managers, it’s built around authenticating into websites, not everywhere - so it doesn’t eliminate passwords either. And despite how far biometrics have come, you always have a password sitting there as the fallback. What we end up with is a whole zoo of solutions, each solving its own narrow case, each with its own fallback. My view of where authentication is headed is a purpose-built device for storing passwords. It needs no configuration, a child could use it, and it works everywhere. That device should take over three functions: generating, storing, and typing passwords. It’s extremely hard to compromise, it works everywhere, and it genuinely makes life easier. Say you’ve got LUKS with a keyfile - you still need to back that keyfile up somewhere, and that’s exactly what a device like this is for. You can set up your KeePass database to unlock via YubiKey - but you still need a fallback password, which can live in that same device. You might have TPM - but you still need a PIN and a solid PC user password, and all of that can be stored somewhere you can actually retrieve it from later. --- ## Post 43 by @racky — 2026-09-02T09:41:57Z > [@s0k0l](#): > > The database gets decrypted inside the OS, in RAM, right next to the browser and every other running process. > [@s0k0l](#): > > But they do nothing against a threat that’s arguably far more common in practice - malware on an already-unlocked system, which steals the master password and the entire database in one go. So I guess, installing Microsoft software - which has AI integrated and [a track record of argubly evil data gathering](https://discuss.privacyguides.net/t/new-outlook-sends-all-your-emails-to-microsoft/14965) - on same machine/system as KeepassXC (or any other password manager) is a bad idea? --- ## Post 44 by @Gersand — 2026-09-02T09:59:11Z > [@s0k0l](#): > > Nextcloud isn’t really “getting passwords off the PC” though - it’s “duplicating the secret data in one more place” and “making your secrets reachable over the network 24/7.” Yes, sorry. I had not realised your goal was to completely get secrets off the PC. > [@s0k0l](#): > > And it raises its own question: where do you store the credentials for the cloud connection itself? The user credentials are inside the KeepassXC database. My sync clients (on PC and Phone have their own (super long, random and complex) “app password”. > [@s0k0l](#): > > Backups are always needed, that’s a separate concern - and that’s exactly what you set up Nextcloud for, which makes sense. But it’s not an alternative to getting secrets off the PC, it’s just backup redundancy layered on top of whatever solution you’re using. True. As confessed above, I had not realised the goal was to have secrets off the PC. Nextcloud is for me at the same time a backup and a way to have ubiquity for my database. > [@s0k0l](#): > > And there’s another important point: if the setup breaks - the keyfile USB fails, the YubiKey dies, or the hard drive itself goes - there has to be a fallback to a plain password everywhere. Which means those passwords need to physically exist somewhere, There is. That’s why I have 2 databases side-by-side: one opened by Yubikey, that is empty with only an AutoOpen entry to auto-open the second with a very strong plaintext password, which contains all my secrets. The password is impossible to remember or bruteforce with the foreseeable technologies, In my personal case, I store it on a note, hidden in my house. When I advise this setup to clients, I recommend having that last-recourse password on a note stored in a bank’s physical vault (surprisingly cheap, like $50 per year). Also, ideally, there are two Yubikey in case one fails. If the hard drive fails, it’s really not a problem as the DB is sync’ed in the cloud. > [@s0k0l](#): > > along with the Nextcloud credentials, because if the hard drive fails, the KeePass database becomes completely unreachable. So you’re required to have offline backups of your access credentials - on a USB drive, for instance. This doesn’t apply owing to the “app passwords” supported by Nextcloud. The problem would only be the situation where I lose access to both my phone and my PC at the same time (which _could_ happen, admittedly). --- ## Post 45 by @s0k0l — 2026-09-02T10:24:24Z Microsoft routinely builds backdoors into the system, so if you’re, say, a journalist hiding from your own government, their products are a genuine liability for you. For some categories of users, that’s not paranoia, it’s just a fact. But it’s not only about telemetry from specific proprietary vendors either. Think about it: a fresh PC doesn’t ship with gcc or make. But you install PyCharm and Python header packages for dev work - now the machine can compile code, and you’ve got Java sitting there too. You just expanded what an attacker can do in post-exploitation. You wanted to play a game with a friend over the network, downloaded a mod on his recommendation, that’s it. You started a new job, got a PDF payslip in your inbox, opened it, that’s it. You installed Microsoft Teams for work, and it turned out to be riddled with holes and leaking telemetry on top of it. All of that happening in parallel while you’re trying to protect a password database. You can get compromised at any level - it all depends on who’s actually hunting you. --- ## Post 46 by @Gersand — 2026-09-02T10:35:38Z On your second more general post. I now see more value to hardware password manager, thanks for this. But it does come with its lot of precautions and pitfalls, I think. First, it can also break, get lost or stolen. So to be on the safe side, you would need to have two sync’ed devices (not stored in the same place), or to be able to create regular well-encrypted dumps that you would have to store on some device or cloud. Second, in case someone finds it or steals it, I guess there is a PIN or fingerprint reader ? That must be thought of. Is the PIN brute-forcing impossible? Third, is the embedded software, USB-driver/bluetooth-stack secure? Passwords must indeed become impossible to generate and remember by a human because of AI and GPUs power. But at the end of the day, the only reliable master key would be biometrics (like on fingerprint Yubikeys, for example), addressing the losing/stolen device issue. But while biometrics is the ultimate security lock, it’s also a killer for anonymity and plausible deniability. On possible way, for some really specific situations, is to make a small executable (with obfuscated code) that will generate and retrieve the master key based on its environment (local network MAC addresses or other constant information, with tolerance for one or two missing bits in case of some device failure), so that the executable can retrieve the master key only if run in a specific environment, like “my home with my ISP router, TV and printer turned on, both my and my partner’s phones reachable”, or like “my work, with local domain DNS and at least 50 computers reachable” etc. (with tolerance for a few criteria missing). But I don’t know how robust is obfuscated code against strong reverse engineering… Well, I got a bit lost. Endless and interesting conversation… --- ## Post 47 by @Gersand — 2026-09-02T10:41:50Z Microsoft could go bankrupt if someone could prove they steal data from a password manager. So I think they are very likely to refrain from doing that. By the way, I think it has more chances to happen in the Linux realm, if some obscure team comes up with a new super fancy distribution with great design and UX, and performance/security-oriented branding. The devs can remain unknown and accountable to nobody. But yes, theoretically, it’s possible. --- ## Post 48 by @Gersand — 2026-09-02T10:48:13Z > [@s0k0l](#): > > Personally, I don’t see much point in storing encryption keys on the same hardware you’re trying to protect The main point of TPM (if properly implemented), is to hold a read-only pair of public-private keys. The private key signs the boot material, the public key checks the signature at every boot, in order to check the boot material was not tampered. Then, as any device, it might be used to secure other secrets, but as you point, it doesn’t add a lot of value for that use case, except in one case: if you want some secrets to be retrievable only on that particular computer. --- ## Post 49 by @foolclown — 2026-09-02T11:46:03Z Thank you for answering my question :slight_smile: --- ## Post 50 by @foolclown — 2026-09-02T11:47:50Z > [@Gersand](#): > > if some obscure team comes up with a new super fancy distribution with great design and UX, and performance/security-oriented branding _cough_ Omarchy _cough_ I jest --- ## Post 51 by @s0k0l — 2026-09-02T12:27:33Z Thank you for the understanding and the first respect from a stranger. You’ll stay in my heart forever. > [@Gersand](#): > > First, it can also break, get lost or stolen. So to be on the safe side, you would need to have two sync’ed devices (not stored in the same place), or to be able to create regular well-encrypted dumps that you would have to store on some device or cloud. That’s really cool, though I think hiding an SD card with the backup would be easier. And you can still take it to a bank deposit box. And it turns out passwords don’t actually get rotated that often. I’m a fan of open backups, by the way, so access can still be recovered even in an Alzheimer’s scenario - either because I know how to build password-protected archives, or because I know PGP, or because I’m worried there’ll eventually be a need for a note with the backup password anyway. > [@Gersand](#): > > Second, in case someone finds it or steals it, I guess there is a PIN or fingerprint reader ? That must be thought of. Is the PIN brute-forcing impossible? I think you need both PIN and biometrics. There’s no getting away from a password entirely - otherwise what do you do if the hand is gone but the biometric check is still there? PIN protection against brute-force is classic: 3 attempts and a full wipe. Beyond that, since it’s a purpose-built device, there’s room to design other protections into the hardware that software just can’t offer in the same way. > [@Gersand](#): > > Third, is the embedded software, USB-driver/bluetooth-stack secure? WiFi is only for admin actions (an SSL-secured site). I’m pretty doubtful about Bluetooth and don’t recommend it, but USB-HID didn’t work on iPhone, so Bluetooth ended up in there anyway, and I’d genuinely welcome someone auditing it. USB-HID is an open protocol for input devices talking to a computer. An attack on it means intercepting the signal. If someone’s attached a rogue device to your keyboard cable, using a separate device for typing passwords removes the payload for that bug entirely. Oh, and if anyone thinks they’re safe using a wireless keyboard or mouse - nope, it’s actually worse xD. If the interception happens inside the OS - meaning the same signals, just going from OS to the target app - there’s nothing to be done about that (yet). The difference is that the rest of the database stays out of reach either way. > [@Gersand](#): > > But while biometrics is the ultimate security lock, it’s also a killer for anonymity and plausible deniability. Biometric authentication has one unpleasant property: you can’t hand it over, but it can be stolen. xD > [@Gersand](#): > > On possible way, for some really specific situations, is to make a small executable (with obfuscated code) that will generate and retrieve the master key based on its environment The only constant in life is change. Separately, about the chip itself: I haven’t researched how well microchips are protected as a general category, but the ESP32-S3 specifically has built-in encryption mechanisms. Everything gets encrypted, including the bootloader itself. There are eFuse bits for encryption and debug - these are physically irreversible changes burned into the chip, after which it can keep its encryption keys secret and refuses to run unencrypted firmware or expose access through debug interfaces. I’m not sure how strong that protection actually is, or whether it’d hold up against lab-grade side-channel attacks and all. --- ## Post 52 by @s0k0l — 2026-09-02T18:20:10Z > [@Gersand](#): > > Third, is the embedded software, USB-driver/bluetooth-stack secure? Dug into this a bit more, by the way - looks like one layer of protection isn’t going to be enough here, I’ll need a separate security module on top. --- ## Post 53 by @Libre_Software_Enjoyer — 2026-09-02T19:01:19Z > [@s0k0l](#): > > A hardware password manager, as I currently picture it, won’t protect against a keylogger - the base version uses USB-HID emulation, and that’s an honest limitation. But it does three other things that software solutions handle far worse: > > First, it physically isolates the entire database from anything running inside the OS. Second, it gives you maximum protection instantly, with zero configuration, because it handles password generation, storage, and keyboard input all in one. Third, it gives you the convenience of a cloud solution - access from anywhere - without creating the attack vectors that come with actual cloud solutions. Why not use a hardware wallet with U2F and/or FIDO support for this purpose? It also solves the problem of keylogging --- ## Post 54 by @s0k0l — 2026-09-02T19:43:19Z The key thing is that all these standards require structural changes - new protocols, service-side support, integration effort on both sides. What I’m thinking about is one device that just works everywhere, immediately, because it doesn’t require rebuilding any part of the internet. And passwords will stay with us forever, even after computers themselves stop existing as we know them. --- ## Post 55 by @Libre_Software_Enjoyer — 2026-09-04T01:14:45Z > [@s0k0l](#): > > The key thing is that all these standards require structural changes - new protocols, service-side support, integration effort on both sides. Most software solutions that are available for a free or a small fee have at least 2FA/U2F integrated. And the rest is not that important that it justifies a hardware password manager only for this purpose. But maybe a allready existing hardware-wallet/security-key could implement a feature like this. --- ## Post 56 by @racky — 2026-09-05T08:00:14Z > [@Gersand](#): > > Microsoft could go bankrupt if someone could prove they steal data from a password manager. So I think they are very likely to refrain from doing that. Let me look into the crystal ball: “We’re so sorry, our AI autonomously scraped all your disk data (btw: you should watch less pr\*n). Of course we are deleting everything (despite being contrary to our business model) !11 Oh wait … we already sold your data to X brokers, damn.” There still is a legal grey border with responsible usage of AI, few or no regulation of it, also taking into account their rising capabilities. Even AI hacking other companies didn’t have further consequences. These tech companies already have legal expenses priced in their business model. Scraping as much data as possible seems to monetarily be worth it - data needs to efflux just once, profit stays. Legal expense costs do not make up for it. Just recently Meta willingly paid 15 billion dollars to not be legally responsible for child/adolescent protection. Hence I am not as confident as you. --- ## Post 57 by @privacyisconsent — 2026-09-05T09:29:01Z @s0k0l Have you looked into existing solutions in this space (hardware password managers)? Here are some from my notes: - [Mooltipass Mini BLE](https://www.themooltipass.com/) out of stock hardware password manager - [Onlykey](https://onlykey.io/) pin-protected hardware password manager without a display - [Authorizer](https://github.com/tejado/Authorizer) with an offline Android device - [Keepass2Android](https://github.com/PhilippC/keepass2android/blob/f08f906fa105697a6ba6739deed0233e47434216/docs/Available-Plug-ins.md#inputstick-plug-in) + [inputstick](https://www.inputstick.com/) with an offline Android device - [ZeroKeyUSB](https://zerokeyusb.com/) upcoming hardware password manager - [Trezor Password Manager + Browser Extension](https://trezor.io/guides/bonus-tools/trezor-password-manager) deprecated feature of Trezor wallets --- ## Post 58 by @Gersand — 2026-09-05T09:30:45Z I am not really confident. But the scenario you describe, when happening, would certainly make millions of people (and worse : businesses) leave Microsoft the next day, that’s what I meant. > **Off-topic, about the autonomous AI thing.** > > Additionally, don’t fall for those “autonomous AI that attack and hack things by themselves”. It’s pure marketing bullshit in an arena where the fighter are 25-50 y-o rich male geeks who spend their time comparing the size of their models. > > Their branding rhetoric is centred on power, strength and domination, so their communication plan to raise billions (whereas they barely make some millions of income) is to assert how dangerous (therefore strong, therefore bankable) is their AI. > > So far, no AI at all has ever done any unexpected thing, even when their creators said the contrary. When AI attacked, the setup was “we give our model in some difficult task to do, we lower all the security and ethic boundaries, we leave some normally forbidden door accessible but locked, and we watch whether the model finds the door and breaks the lock”. When it does, they tell journalists that the AI escaped on its own, that it’s a massive beast, as their… model, etc. > > Note : I am not an AI fan and I mostly despise companies like Google, Anthropic, OpenAI, Microsoft, Meta, Amazon, their Chinese or Russian counterparts whose name I don’t know etc. --- ## Post 59 by @s0k0l — 2026-09-05T13:40:57Z Yeah, I’ve looked into them. But all of them are either a) screenless, and b) dependent on software on the computer because of that. And all of them are abandoned. A screen is genuinely useful - yes, it makes the device a bit bigger than just a flash drive (and everyone loves making something super tiny and super capable), but it lets you use the device completely on its own, independent of the PC. No integration required at all - no APIs to call, no apps to install, nothing to configure. Why would I want to manage this through software on the PC, when the whole point is using it while turning the PC on in the first place? :slight_smile: --- ## Post 60 by @s0k0l — 2026-09-05T13:53:26Z I think you’re mixing two different categories here. “Everything already covered by 2FA/U2F” is usually logging into websites and services where someone on the service side bothered to implement the protocol. “Everything else” isn’t the minor stuff though - that’s LUKS, root, the KeePass database itself, crypto wallet seed phrases - literally the secrets that unlock everything else. I wouldn’t call that unimportant just because there’s no ready-made protocol for it. And on “let an existing security key add that feature” - there’s an architectural issue there. YubiKeys and similar devices are built around challenge-response: the device confirms it’s you in response to a specific request from the service. What’s needed here is something different - arbitrary text typed into an arbitrary field, with no protocol on the other end at all. That’s not a feature you bolt on top, it’s a different core mechanism for how the device works. --- ## Post 62 by @s0k0l — 2026-09-05T20:29:26Z I’m not a native English speaker and I use a translation tool to phrase my thoughts more precisely in English. The content, the arguments, and the position are entirely my own. Did you actually read through my arguments? Do you have any questions, or did you spot a more substantial problem with them? --- ## Post 63 by @xra — 2026-09-05T20:47:09Z I would rather handle bad grammar than not knowing if you are real or not. I think just having an old phone you don’t connect to the internet or a password book works better than every other option. Much more secure. --- ## Post 64 by @Gersand — 2026-09-05T21:13:21Z Secure passwords are nowadays rather 20+ characters of random characters of every sort. 30 is better. Of course, it depends of the authentication scheme, but you don’t always know the scheme so safety suggest to assume the worst. That said, when you have 10-30 passwords to enter everyday among a total of 300+ (some possibly rarely used), searching a book for them and typing those complex strings while reading them is not an option any longer. Even an old phone might (or not) offer lookup capability but one will need to read and type long and complex passwords all the time, which can be too cumbersome in some use cases. --- ## Post 65 by @s0k0l — 2026-09-05T21:33:52Z > [@xra](#): > > an old phone you don’t connect to the internet or a password book works better than every other option A password on a piece of paper is not about security, and we’re all here about security. When you type a password by hand, it can be: 1. spied on where your fingers are pointing 2. overheard where your fingers are pointing 3. intercepted as signals from the keyboard to the PC, this is easier with wireless keyboards And in general: 1. at any moment, anyone can take a photo of your piece of paper 2. the piece of paper can very easily become unusable And also 1. it’s very tiring to enter long unpredictable sequences --- ## Post 66 by @Libre_Software_Enjoyer — 2026-09-05T23:40:07Z > [@s0k0l](#): > > I think you’re mixing two different categories here. “Everything already covered by 2FA/U2F” is usually logging into websites and services where someone on the service side bothered to implement the protocol. “Everything else” isn’t the minor stuff though - that’s LUKS, root, the KeePass database itself, crypto wallet seed phrases - literally the secrets that unlock everything else. I wouldn’t call that unimportant just because there’s no ready-made protocol for it. > [@xra](#): > > I think just having an old phone you don’t connect to the internet or a password book works better than every other option. Much more secure. Much more secure against which type of attack? If the device you will type the password in is hacked, then its doesn’t matter if your password manager is offline. --- ## Post 67 by @racky — 2026-09-06T07:40:18Z > [@s0k0l](#): > > The database gets decrypted inside the OS, in RAM, right next to the browser and every other running process. Having read a bit more on it, KeepassXC at least [prevents memory dumping](https://keepassxc.org/blog/2019-02-21-memory-security/) from non-root, so malware with same user privileges can’t extract contents. > [@s0k0l](#): > > If a machine gets hit with an infostealer, the attacker doesn’t need to crack anything - they get the master password and the decrypted database in one pass. On Linux, in theory you should be able to leverage separate users for more isolation and protection against keyloggers, shared clipboard and screen capture. But that probably is a cumbersome endeavor, since “How to transfer your password from KeepassXC to program X” still needs to be solved. Browser integration and copy/paste of credentials require same user. > [@TheDoc](#): > > his is where security keys (especially [YubiKeys](https://www.privacyguides.org/en/security-keys/#yubikey)) are very useful. An infostealer on your computer wouldn’t be able to access your passkey private keys or TOTP secrets, at worst they should only gain temporary access to your accounts. Yes, security tokens IMO only make sense with passkeys given this threat model. Otherwise a key logger might sniff password in cleartext when in transit from hardware token to destination app, same as with software password managers. Passkeys = private key part never leaves token. > [@Gersand](#): > > #Off-topic, about the autonomous AI thing. > > Additionally, don’t fall for those “autonomous AI that attack and hack things by themselves”. It’s pure marketing bullshit in an arena where the fighter are 25-50 y-o rich male geeks who spend their time comparing the size of their models. > > Their branding rhetoric is centred on power, strength and domination, so their communication plan to raise billions (whereas they barely make some millions of income) is to assert how dangerous (therefore strong, therefore bankable) is their AI. > > So far, no AI at all has ever done any unexpected thing, even when their creators said the contrary. When AI attacked, the setup was “we give our model in some difficult task to do, we lower all the security and ethic boundaries, we leave some normally forbidden door accessible but locked, and we watch whether the model finds the door and breaks the lock”. When it does, they tell journalists that the AI escaped on its own, that it’s a massive beast, as their… model, etc. > > Note : I am not an AI fan and I mostly despise companies like Google, Anthropic, OpenAI, Microsoft, Meta, Amazon, their Chinese or Russian counterparts whose name I don’t know etc. I also thought this AI hack to be a marketing campaign. But security researchers reported, that obviously [new versions even manage to hack out of a VM](https://blog.trailofbits.com/2026/08/26/vms-wont-contain-cyber-capable-agents/) (also linked [here](https://www.schneier.com/blog/archives/2026/09/using-a-vm-to-contain-an-ai-agent.html)). --- ## Post 68 by @s0k0l — 2026-09-06T10:15:50Z I want to close the topic of TOTP and other two-factor methods, because that’s just not what this is about. We’re not in the business of protecting one specific password - that’s exactly what TOTP protects. Our problem is different: every current password storage solution is software-based. There’s a program running inside the OS, and to reach it you already need to type some password, and to open the program itself you need another one. And no amount of TOTP or any other factor fixes that, because even if you add it, you still have to type the password manager’s password first, and then a TOTP code on top of that. And TOTP isn’t a silver bullet either - it doesn’t protect a password 100%, it’s just one more factor. TOTP is a secret that lives both on the server you’re logging into and on your device. If I attack the server and steal that secret, I can generate your codes. If I attack you and steal your secret, I can also generate codes and log in just fine. > [@racky](#): > > Having read a bit more on it, KeepassXC at least [prevents memory dumping](https://keepassxc.org/blog/2019-02-21-memory-security/) from non-root, so malware with same user privileges can’t extract contents. The fact that a non-root user can’t dump RAM and KeePassXC’s protection holds up against that isn’t a silver bullet either, because there are plenty of ways to escalate privileges in post-exploitation, and new ones show up every day. We can’t prevent that, we can’t outrun it. Tomorrow an OS kernel update ships that closes one hole - and opens a new one we don’t know about yet. And we’ll never know in advance whether our password database got stolen, whether the machine is infected or not. It’s simple: computer viruses get created first, then deployed, then they spread across the world, and only after that do antivirus companies find them. Then they spend a long time figuring out an algorithm, working on heuristic analysis, building pattern signatures - and only after all that does protection actually ship. Even with antivirus running, you’re protected against maybe 60-70% of already-known attacks. Not the rest of the known ones. And not against the ones nobody knows about yet, by definition. > [@Libre_Software_Enjoyer](#): > > If the device you will type the password in is hacked, then its doesn’t matter if your password manager is offline. And it’s exactly right: if your computer is compromised, it doesn’t matter whether you have TPM, a YubiKey, or anything else. If the machine is infected and the password database sits on it, that database is most likely compromised too, and every password has leaked. And the entire point of a hardware password manager is precisely to keep the database safe from anything malicious running inside the OS. --- ## Post 69 by @privacyisconsent — 2026-09-06T10:36:40Z As far as I’m aware, after setup you can use Mooltipass and type passwords over USB without using the desktop/mobile application or browser extensions. So it more or less meets your needs. It then becomes more of a question of securing and backing up the hardware password manager for which you would probably need to leverage the knowledge and experience of cryptocurrency hardware wallet makers. --- ## Post 70 by @Gersand — 2026-09-06T14:20:55Z > **off-topic : autonomous AI** > > > I also thought this AI hack to be a marketing campaign. But security researchers reported, that obviously new versions even manage to hack out of a VM (also linked here). > > Sorry if I wasn’t clear. I don’t say AIs are not capable of doing this. I say they won’t do it by themselves out of the blue, they will just do it if they are asked or at least induced to, and if their hacking capabilities are not prevented. > > You and I can safely put that same AI in our VM, it will never evade from it, because we won’t ask for it or ask for something that requires to escape, and we won’t remove the securities and ACLs/DCLs preventing unauthorized access. > > From a Cybersecurity point of view, they will be great guinea pigs able to find new vulnerabilities. They will not be a threat by themselves. They can become a great tool for threat actors too, like any pentest tool (metasploit, searchsploit etc.). But there is just nothing new here. Security-conscious people will use the best tools to test their setup before hostile actors use those very tools to attack them. --- ## Post 71 by @s0k0l — 2026-09-06T17:26:05Z > [@privacyisconsent](#): > > after setup you can use Mooltipass and type passwords over USB That’s true, you’re right, it’s generally possible. And that’s exactly what I’m talking about. Still, in my view, there are very few devices like this, and at best they’ve got a 90s Casio-watch-level indicator screen - good for icons, not for actually managing entries. They’re not built to handle a large number of entries, don’t organize records, and don’t have enough security mechanisms. If you suddenly need to set up a couple of new accounts, you end up fiddling with the connection process. And on top of that, it depends on whether the developer of that particular device happened to be paranoid enough to set up SSL on the local network - or not. --- ## Post 72 by @xra — 2026-09-07T02:22:29Z I feel like no solution can fix that, except USB keys. I wouldn’t stress out about that too much though, if you are doing everything right that is probably not an issue. --- ## Post 73 by @winteranimal — 2026-09-07T13:35:26Z > [@s0k0l](#): > > What if a hardware password manager typed the passwords for you instead - via keyboard emulation, no clipboard involved at all? And worked the same way everywhere: Windows, Linux, Qubes, phone - no software, no VM setup, no tradeoff between convenience and isolation. Plug it in, use it. That would be great for threat models that don’t include the key being stolen. Its a trade off. In one case, you forced to remember N passphrases, at least two of which must be long enough to have enough entropy. On the other, your guarding an extra device. If there was a good solution for all cases, it would become standard practice and we’d be discussing edge cases from there. Keeping your passphrases and passkeys on a phone is inconvenient when your using another device. Its a trade off. The purpose of a password manager is security, so I think the tradeoff is worth it. Most of those things will happen directly on the users phone anyway. Most services on desktop support passkeys. --- ## Post 74 by @Libre_Software_Enjoyer — 2026-09-09T21:10:18Z > [@s0k0l](#): > > And the entire point of a hardware password manager is precisely to keep the database safe from anything malicious running inside the OS. Every password the hardware password manager sends to the compromised OS, will then also be compromised. Hardware wallets and security keys only improve security, because they use asymmetric cryptography and the actual secrets, never leave them. This model doesn’t work with symmetric passwords. --- ## Post 75 by @s0k0l — 2026-09-10T12:55:06Z > [@winteranimal](#): > > That would be great for threat models that don’t include the key being stolen. Turns out the device itself is very easy to keep secure. A keyboard is the base device for input, and it’s mandatory - no passkeys will save you from a login form, which isn’t going away. And in some cases passkeys aren’t even available for integration, because the protocol requires both sides to store and use private keys somewhere. You can’t hold private keys in your head, so you need a device. Now you’ve got both passwords and a device you need to protect. Add TOTP - now you need to store a password, a secret, and the device itself, all somewhere. And all of that needs to be kept and protected somehow. I look at a keyboard and see a microcontroller with buttons. So here’s an idea: a special add-on for the keyboard, with a screen - you pick what to type on the screen, tap a touch button, and the mechanism types it out on the keys itself. That, to me, solves nearly all of these problems at once. How do you attack a device like that remotely? Basically you can’t - the realistic vector is mostly physical. And I can pick up a virus anywhere, but physically, nobody’s ever tried to attack me for passwords - except once, when someone glanced at one over my shoulder. --- ## Post 76 by @s0k0l — 2026-09-10T13:03:01Z > [@Libre_Software_Enjoyer](#): > > Hardware wallets and security keys only improve security, because they use asymetric cryptography You’re absolutely right. The solution should also support asymmetric authentication as well. By the way, even SSH keys have password protection - so it’s not the password being protected by the key, it’s the key being protected by a password. --- ## Post 77 by @winteranimal — 2026-09-11T00:11:35Z This is what FIDO keys are for. If your going to go the usb keyboard route, make it tamper proof with a pin. The usual is self destruct (or just self delete) if the wrong pin is entered a few times. Then encase it all in epoxy or something and wear it as jewelry, like a ring or bracelet. But you still can’t get around the need to compartmentalize. As said before, if the os is compromised, it will still read your password. If its just a malicious app, the os might save you by hiding keyboard input from the non focused app, but thats a cat and mouse game, esp with accessibility helpers in some desktops. Mac and linux (wayland, and some rare instances of X11) have this. Windows probably does too. The ideal is a separate source of all secrets, and everything compartmentalized. Then, when you find out something bad happened, be it malice, mistake, or misfortune, the damage is contained and likely easy to simply restore from backup going back however far you need to. You do keep incremental backups, right? --- ## Post 78 by @s0k0l — 2026-09-11T09:20:26Z > [@winteranimal](#): > > This is what FIDO keys are for. FIDO doesn’t free you from having to come up with, remember, and type a password. And you don’t need to pot the whole enclosure in epoxy - a drop of epoxy on the chip itself is enough. Brute-force protection already exists. Wearing it as jewelry won’t really work though, because the device still needs to be managed somehow. Without a screen, it’s a dependent device, and then you need two devices on hand at once. I think a solution like this should have the following properties: 1. Work Plug&Play anywhere there’s a USB-HID interface. 2. Be self-sufficient - the password manager is operated entirely through the device’s own interface. 3. Hold enough entries for one person - somewhere in the tens of thousands, with multiple fields per entry, so it can store not just the password but metadata around it (security questions, linked email, phone number). 4. With that many entries, you need a search system - tags that let you group entries by type. 5. The solution needs to be protected - both from an attack via the connected device and from direct physical attack. 6. The solution needs to support backups and updates. 7. Even with physical possession of the device, it should be impossible to assess the information stored inside it. A solution like that isn’t just capable of typing a password anywhere - it also contains the damage when something goes wrong. Yes, I do keep incremental backups - I use Git for that.