Add option to search for passwords

[Chefkeks]

Hi there,

just had the case that I wanted to search for a password as one of my accounts got unfortunately published on HIBP which I just recognized :/

I usually use a different password for each service / account, but wanted to make sure that I haven’t used the leaked one somewhere else. As I have several hundred passwords it’s not an option to look at all of course to make sure that only that one account/password is affected. That said, KeePassium seems only support searching for title, username etc. but you cannot search for passwords.

How about adding a button on the right side next to the search bar where you can select via a dropdown or popup menu what attributes are searched. This would make it possible then to search passwords too for users who need this (temporarily or permanently) and also allow too keep the current behavior searching title, username etc. as default.

Thanks in advance Michael

[keepassium]

Thanks, Michael.

I agree, this makes sense as an option. In general, searching among passwords did not seem useful, but your scenario sounds perfectly valid. I will add this once I get to improving the search. Thanks again!

[bsidhom]

I can see this being a useful feature, but please consider the security implications of the implementation. For example constructing an in-memory index of the passwords themselves adds a lot of plaintext exposure in memory which the KDBX format attempts to mitigate by double-encrypting. You may be able to use some sort of homomorphic encryption indexing or HMAC-index trickery to do this more safely, but it's more reliable to just scan through the entries on-demand (decrypting to check for a match, then re-encrypting on failure to match) if search is requested.

A better alternative might be to disable a password searching feature unless explicitly opted in.

For anybody missing the motivation for this: Row hammer-like side-channel attacks make this sort of defense-in-depth valuable, e.g., in the face of malicious apps. It's preferable to have a single password exposed at the time it's being used than to have the whole DB available in plaintext the entire time the DB is open.

[keepassium]

@bsidhom , thanks for the feedback.

I'm afraid the extra exposure would not matter, because loaded database is stored in memory already in plain text. Inner KDBX encryption is decrypted at the DB loading stage. The reasoning behind this decision was two-fold:

• Search is the most likely use case in mobile scenario (hypothetically). So it does not make much sense to delay full decryption until the user starts typing.
• There is no reliable way to clean up a Swift string — there are too many self-conscious layers between my code and the actual byte array. Once KeePassium builds a plain-text string, the app can only memset_s its own copy — but the system might keep a few other copies. (Hopefully deallocated, but not zeroed out.)

The second issue applies to other apps as well. KeePassXC also pre-decrypts protected fields and stores them in plain text, because Qt framework abstracts most of memory management out. KeePass keeps protected fields encrypted until they are required, but also acknowledges that Windows/.NET can retain their own copies.

In this context, I see two possible solutions:

• Go deeper and implement a custom low-level encrypted string, plus custom UI elements to display it. This perspective does not seem too exciting, to be honest: Unicode is insanely complicated.
• Give up in-memory protection of entry fields as infeasible, and focus on protecting DB keys instead. (Using the Secure Enclave. I am pushing this in a couple of days.)

[bsidhom]

Thanks for clarifying the situation; that makes sense. I thought that was a possibility, but haven’t had a chance to look at the protected entry code yet. Yes, given the state of affairs, the only realistic option to address the in-memory issue is to use a native library that does not use, e.g., interned strings (and I’m not even sure how feasible this is with UI frameworks in general, short of handling text painting manually). I still think it’s worth at least considering the total plaintext incidence just because most memory attack vectors are probabilistic and having twice as much plaintext payload doubles the chances of randomly hitting “interesting” memory locations.

I agree that protecting the DB key is much more important, and I’m glad to hear about using the Secure Enclave for this!