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.
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 ?
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?
I never type passwords. But now and then, I copy-paste them from KeePassXC’s database.
Good, are you don’t have luks encryption and auto login enabled?
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.
2 Likes
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.
1 Like
And what are you think about a harware password manager?
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.
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.
Therefore you should only install trusted software and install everything else in a sandbox, like Flatpak.
I am keeping some credentials only on my phone (GrapheneOS), since its far less likely to get hacked.
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?
I can copy from KeePassDX on and then past it into the credential field of whatever service I want to use.
I think max security devides have some merit.
For example hardware wallets that can handle crypto transactions, U2F and FIDO are very beneficial
Have you checked KeepassDX magic keyboard feature ? You don’t even need to copy-paste…
I have a Nextcloud instance synchronising several devices, for this.
I have never been in those situations, and don’t plan to be in a foreseeable future.
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?
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
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.
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.
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.
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.