walliss fitzpatric madoch

0 views

Skip to first unread message

Coleman John

unread,

Aug 2, 2024, 9:05:17 PM8/2/24

to quicretimam

I'm looking at a solution like Strongbox or KeePassium as I almost exclusively work in the Apple ecosystem and they seem to be highly recommended. They also seem to support cloud storage sync, which I'd like to have if possible.

I'd be looking to secure my database with a strong master password as well as a set of YubiKeys, but I am unclear if the YubiKeys are tied to the specific app or if it's actually a feature of the KeePass database format and could be opened with something like KeePassXC if Strongbox went out of business suddenly and stopped working for whatever reason.

Assuming that I have a database setup with a secure master password and YubiKeys even if someone were to access my database file and have my master password, would the YubiKey protect it regardless of what application they were using? The concern obviously being that once the file is out there, it's out there. Unlike something like 1Password where you can revoke access to a degree.

If anybody could shed some light for me that'd be great! I did do a good bit of research but due to all the different variations nothing seems super straight forward to me and I run on the paranoid side.

These are independent apps by different developers, so they vary by design, support and amount of extra features. But their common denominator is the database format, so every app will support the main features features. (Just like any spreadsheet app would open and edit an Excel file, even if without fancy formatting.)

As secure as it gets: it is well-encrypted, it has protection against dictionary attacks, and you can control the level of that protection. The database file is always encrypted, the data is decrypted only to device memory (RAM). Theoretically, one can even publish their database online for everyone to see. Without the master key, it's just an encrypted binary blob.

First of all, make sure you get the genuine app. There are a few websites with a fake "KeePass". There used to be an iOS app called "KeePass" that simply abused the name and had nothing to do with the real app.

Then, google the app history/reputation. There are apps that should be open, but they don't release their source code (KeePass Touch). There was an app that looked fine, but started behaving suspiciously and its dev simply shut down the project without much explanations (IOSKeePass/KeePassMini, not to be confused with MiniKeePass).

YubiKeys are not tied to the specific app. So yes, you can open a YubiKey-protected database in KeePassXC, KeePassium, Strongbox, Keepass2Android and probably some other apps. (Remarkably, not in KeePass: its only YubiKey-related plugin, KeeChallenge, uses its own encryption scheme and ought to be avoided.)

However, YubiKey are not a feature of database format, either. It is more of an after-market extension to the algorithm that calculates the encryption key from its components. Database file does not contain any indications of which key components are used. It just takes whatever master key the user provides, and tries to decrypt the database using these data.

where yubikeyResponse is the data returned by YubiKey's HMAC-SHA1 challenge-response (CR) feature. There, the YubiKey serves as a black box that receives some data (challenge), transforms it in some predefined way (based on a secret you configured during YubiKey CR setup), and returns the transformed result (response). This computation does not leave any traces on the YubiKey. The challenge is just a sequence of random bytes stored in database header in plain text, it is re-randomized whenever you save the database.

As a side effect, if you store the same secret on two YubiKeys, they will behave exactly the same in CR mode and can be used interchangeably. This is handy as a backup in case your main key is lost or damaged.

But yes, there is always a risk of a rogue update. It won't be intentional, mind you, because both KeePassium and Strongbox have a lot at stake (not anonymous, in European countries with strong laws, are the livelihood of their authors). But bugs happen and some of them can corrupt your database, so you should be keeping backups.

As far as I know, this feature only uses the Yubikey as a convenient way to store an encryption key (similar to a keyfile); typically using the HMAC feature that many FIDO keys have (i.e. most likely not using Yubikey-specific traditional functionality). Much like a keyfile, it can be neither bypassed nor bruteforced.

To enable the autotype feature on Wayland, edit /usr/share/applications/org.keepassxc.KeePassXC.desktop and change the value of Exec to keepassxc -platform xcb. Alternatively, set the QT_QPA_PLATFORM=xcb environment variable before launching KeePassXC. However, native Wayland applications will not work with autotype. For example, autotype works when running Firefox without Wayland, but not with.

The feature in KeePassXC is documented in its FAQ. First configure SSH agent to start on login and make sure the SSH_AUTH_SOCK variable is set. Then logout and log back in. Now, in KeePassXC settings, enable SSH agent integration. The SSH_AUTH_SOCK value exposed in the UI should correspond to what you configured earlier.

KeePassXC will refuse to enable its integration if it detects that another program (such as GNOME/Keyring) is already providing that service. You should first stop that program; for example, for gnome-keyring, stopping gnome-keyring-daemon.service user unit.

Note that you will likely want to disable the program permanently, otherwise KeePassXC's integration will fail on the next reboot. Again, for gnome-keyring, disabling the gnome-keyring-daemon.socket (still for the systemd/User).

To enable the dark theme for KeePass, install keepass-keethemeAUR. After installation, the plugin will get compiled upon starting KeePass. It can then be activated via Tools > Dark Theme, or by pressing Ctrl+t.

Some options like Start minimized and locked may appear greyed-out. According to a discussion on SourceForge, since version 2.31, KeePass has disabled two options because of their broken behaviors on Mono.

First, check that the group under which your passwords are stored is exposed; the Tools > Settings menu contains a list of groups enabled for each database. If a database isn't exposing the proper group, select its tab, open Database > Database Settings..., then select the group in the Secret Service Integration tab).

The issue with using Yubikey as login is that the other method are also present allowing an attacker to bypass the Yubikey. However, I supposed using this method may allow you to defeat key loggers, since you would not be entering any passwords.

i would like this feature as well! kinda disapoinnted BW premium does not have.
unlock with the master pw is painful. unlock with pin is not strong enough.
if i want to unlock, the browser extension will prompt to touch my Yubikey. no way for keyloggers to know my master pw nor pin.

In my opinion, the account should allow you the option of blocking the login by user/password, otherwise you leave a backdoor where you can bypass the Yubikey. The proper backup for a Yubikey is another yubikey.

I also vote for passwordless unlock for Bitwardern.
To avoid any issues with stolen Yubikey or leaving it in the computer at home and your kid can unlock it, I would use DUO + Yubikey without any password.
But if you want to login into a new device or after X days, you should enter your password + DOU + Yubikey (or just DUO or Yubikey + password).
So, in this case, it would be convenient enough. You already have Yuibikey on your computer and then just click Approve button on your smartphone.
But it should be configurable. Instead of DUO, we can use email code or SMS, or another OTP application.

I think people are thinking the original ask is for the 2FA to enable decryption of the vault. That is entirely not the original ask. The original ask is for the 2FA to authorize access to the vault (unlock) after it has been locked.

Think of entering the vault password (and 2FA if enabled) as authorizing the sealing and unsealing of the vault. To unlock the vault, you either authorize unlocking with a 2FA or a PIN. The PIN method, being a weaker form of authorization, is merely the fallback for lack of or failed 2FA.

Every time you have to type in a password (or PIN), you expose it to risk. Shoulder surfing, key logging, whatever. Using a 2FA mitigates that exposure by minimizing the number of times you have to expose your PIN or master password.

Adding my voice to this request. Would love to see a setting that splits the difference between the convenience of the lock (and not entering our LONG master passwords), with the security of a log-out (providing a more secure entry barrier). Requiring a hardware key to unlock would be very useful to me, at least.

Requiring the user to unlock using the yubikey. I think the idea is that when you leave, the yubikey goes with you, so that the user is unable to unlock the vault without yubikey. Currently, Bitwarden does not require 2FA when you unlock so the yubikey is never factored in during unlocking. It is a factor only when you log into the vault. I believe this is what the original poster was asking for.