Are software password managers fundamentally trustworthy, or just "good enough"?

[s0k0l]

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.

[racky]

@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 - on same machine/system as KeepassXC (or any other password manager) is a bad idea?

[Gersand]

@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).

[s0k0l]

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.

[Gersand]

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…

[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. 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.

[Gersand]

@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.

[foolclown]

Thank you for answering my question

[foolclown]

@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

[s0k0l]

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.

[s0k0l]

@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.

[Libre_Software_Enjoyer]

@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

[s0k0l]

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.

[Libre_Software_Enjoyer]

@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.

[racky]

@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.

[privacyisconsent]

@s0k0l Have you looked into existing solutions in this space (hardware password managers)? Here are some from my notes:

• Mooltipass Mini BLE out of stock hardware password manager
• Onlykey pin-protected hardware password manager without a display
• Authorizer with an offline Android device
• Keepass2Android + inputstick with an offline Android device
• ZeroKeyUSB upcoming hardware password manager
• Trezor Password Manager + Browser Extension deprecated feature of Trezor wallets

[Gersand]

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.

[s0k0l]

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?

[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.

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.

[s0k0l]

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?