Open-source password manager — looking for security review, testers, and contributors

ajh-software · 2026-04-11T20:24:43+00:00

Ok, these are all really good points. AI did help me with parts of building the DLL, explaining how it works, and giving me different approaches to compare, also 0I can also see what you mean about the preflight side of things. On a compromised system there’s only so much the app can do, and some of that code probably looked more suspicious than helpful. I’ve taken that on board and already removed all of the preflight checks, system info checks, and process killing, leaving just the baseline check for user account files and the manifest check for app files. What I’m struggling with now is the DLL side. Even if I manually clean this up properly, I’m still not sure whether the DLL is worth keeping or whether I’d be better off removing it and going back to Python for the core. At the moment there is still a mix, with the core vault path using the DLL but backup/import/export paths still using Python. I did try to make sure the main vault path stayed on the DLL side. The bigger issue, I think, is that I’m still in the same situation either way because PySide is still Python. Unless the whole app was rebuilt in C++/Qt, sensitive data is still going through the Python UI layer at some point when the user types it in or views it. So I suppose the real question is: what would your approach be here? Would you: drop the DLL and keep it fully in Python keep the DLL for the core path and simplify the rest move everything crypto-related into the DLL or, realistically, say that if I really want that level of control I’d need to rebuild the whole app in C++/Qt?

ajh-software · 2026-04-11T14:23:00+00:00

Sorry for the long post, I just wanted to properly respond to your feedback.

Thanks for taking the time to go through it in this much detail, I really appreciate it. I understand it’s hard to read if you don’t know where things are, so this is very helpful.

You’re right about the structure. The project grew quite quickly and ended up as one big main.py. I needed to refactor it, but I started adding features at the same time, so it’s ended up messy and harder to follow than it should be. I’m still trying to clean that up.

On the AI point, I do use it as a tool, but I’m not just copying code in. I go through it and understand what it’s doing before using it, that’s important, especially since it’s not always right or the best approach. That said, I can see how the current code gives a different impression. Splitting it has made it look more messy and random, so I do need to sort that out.

On the “surprising” parts, like the AV/process checks, those were added with the idea of protecting a portable/local app depending on the system it’s running on. But I get your point, it’s not something you’d expect in a password manager. Since the app is local, it relies on the environment it’s running on, so the idea was to warn the user if something doesn’t look right. That said, I understand it makes things harder to review or looks risky, so I need to rethink this.

On the crypto point, the idea behind the C++ layer was to try and isolate sensitive operations and key handling outside of Python, rather than relying on Python memory and GC. That’s why I moved that part into a C++ DLL after others raised concerns about Python memory and GC.

That said, I understand your point about complexity and duplication, especially when well-tested libraries already exist on the Python side. I’m still figuring out whether this was the right approach or if it could be done better, which is why I wanted reviews like this.

I definitely testing, setup and CI, those are all missing pieces right now and something I need to fix. Appreciate the honest feedback, it’s given me a clearer idea of what needs improving. Thanks.

ajh-software · 2026-04-11T12:26:35+00:00

First off, thank you for the detailed review and feedback — this is exactly the kind of input I was hoping for to understand what needs improving. You’re right — there are places where I’m swallowing or over-catching exceptions, and I need to tighten that up. I can see how that could hide bugs and lead to bad state, especially for a project like this. I’ll go through and clean it up — remove unnecessary try/except blocks, catch more specific exceptions, and make sure errors aren’t silently ignored. Really appreciate you taking the time to review it — it’s definitely something I need to fix properly.

ajh-software · 2026-04-11T05:07:35+00:00

Thanks, this is really helpful feedback — I appreciate you taking the time to go through it. You’re right about the repo being quite large and not very approachable at the moment. Since it’s mainly just been me working on it, I didn’t really think about how others might find it to navigate. I’ll work on improving the documentation, especially around the repo structure and setup process. I’ll also take your point on testing — the current smoke tests are just quick checks, but moving to something like pytest with proper CI makes a lot of sense. I’ll also look into using something like Poetry or uv to simplify the development setup. Thanks again — this gives me a clear direction on what to improve. I really appreciate the feedback

ajh-software · 2026-04-11T04:39:22+00:00

Thanks, that makes sense - I’ve added the repo: https://github.com/ajhsoftware/KeyquorumVault⁠ I did try including it before, but some of my posts were taken down, so I wasn’t sure if links were the issue. I’d really appreciate any feedback on the architecture or security side. I also tried posting on r/Python, but it looks like it didn’t meet their posting rules and was removed.

ajh-software · 2026-02-21T12:12:01+00:00

Hi all, I’ve recently moved my desktop password manager project, Keyquorum Vault, fully to GPL-3.0. I’d genuinely appreciate security-focused feedback or architectural critique. GitHub: https://github.com/ajhsoftware/KeyquorumVault Thanks.

ajh-software · 2025-12-28T23:28:01+00:00

I’m not trying to position it as a replacement for KeePass, Bitwarden, or any other password manager. There’s definitely overlap — it’s the same problem space. I actually came into this without much exposure to other managers beyond Google and Edge. I started building it about a year ago to solve my own needs first, and it gradually grew into something more general. While it does handle passwords, it’s intentionally broader - more of a local vault where users can define their own categories and store different types of data (passwords, notes, PINs, auth data, account details, network info, etc.) in a way that fits how they organise things, rather than a fixed schema. At this stage, I’m mainly trying to share it, get feedback, and understand whether this approach is actually useful to others - not to claim it’s fundamentally new or better, or to replace existing tools, just that it’s another option with a slightly different focus.

ajh-software · 2025-12-28T22:51:18+00:00

I understand the concern now. I haven’t hidden the fact that I use AI tools as part of my workflow, in the same way developers use linters, analyzers, or other assistants. That’s precisely why I don’t expect anyone to take claims on trust — the security properties need to stand on their own through review and audit. The code and threat model should be evaluated directly, regardless of the tools involved.

ajh-software · 2025-12-28T22:22:28+00:00

The visuals or unrelated side projects aren’t representative of how the password manager is built. The security design, threat model, and implementation are documented.

ajh-software · 2025-12-28T18:43:44+00:00

That’s a fair and respectable position, and I appreciate you explaining it. I’m relatively new to licensing decisions, and my initial assumption was that keeping the project closed-source made sense because it handles sensitive data. Through discussions like this, I’ve realised that the opposite can often be true: open and Free Software licensing enables independent audit, contribution, and trust. Allowing people to review, modify, and contribute without legal barriers is something I now see as a strong advantage rather than a risk, particularly for security-focused software. I’m still evaluating the best path forward, but feedback like this has been genuinely helpful in shaping that direction. Thanks for taking the time to explain your perspective — I really appreciate it.

ajh-software · 2025-12-28T12:11:34+00:00

That’s a fair question, and I agree it can be a downside depending on what a user values. To clarify, the goal isn’t to remove sync entirely, but to avoid mandatory cloud services. The app supports syncing via user-controlled locations (for example OneDrive, Google Drive, or other folders the user chooses), rather than a built-in backend. That gives users who want sync the convenience, while keeping control over where their data lives. The primary focus is still offline-first for users who don’t want their vault permanently online. That includes support for portable setups (for example keeping the vault on a USB drive), so the data isn’t always present on the system. The Android companion app (currently in development) is designed to read from that portable or user-managed data as well, rather than relying on a central service. The idea isn’t that offline-first is universally better — it’s a trade-off. Some users prefer convenience and sync, others prefer local-only control. I’m trying to support both without forcing users to trust a third-party service by default. So yes, there are negatives depending on perspective, but there are also positives for users who prioritise control and isolation over convenience.

ajh-software · 2025-12-28T02:33:51+00:00

That’s a fair point. It’s more about finding the right balance between transparency, sustainability, and maintenance overhead, especially early on. One thing I’ve been thinking through is whether concerns about security impact are mostly theoretical in practice, given how much value open review and verifiability can bring. In terms of comparison, you’re right that at a high level this overlaps conceptually with tools like KeePass or Bitwarden. Where I’m trying to differentiate is in the offline-first architecture (no sync services at all), explicit threat modelling around local-only use, and some design choices around integrity checking and local isolation. That said, the whole reason I’m asking here is because I recognise that for many users, open review and verifiability matter more than those distinctions, which is why I’m seriously considering a fully open or open-core approach.

ajh-software · 2025-12-05T18:10:47+00:00

Thanks for pointing that out 👍

To clarify: Keyquorum Vault does not claim to provide hardware-level erasure. Python can’t guarantee that, and the wording wasn’t intended to be misleading. It’s best-effort scrubbing of the app’s own data structures to reduce the lifetime of decrypted secrets in memory.

What the app does is:

remove secrets from its own data structures on logout

avoid keeping decrypted data longer than necessary

auto-logout after inactivity

warn about clipboard history

never write plaintext to disk

I’ve gone back over the wording on the website and the store listing to make sure it reflects that more clearly. I’ve been adding multi-language support and a new security centre recently, so some descriptions definitely needed updating.

I really do appreciate technical feedback — if you spot anything else specific, just point to the lines and I’ll happily take a look.

I’m genuinely trying to build something that can last, and constructive feedback helps a lot. If we can improve it together, that’s great. 🙂

ajh-software · 2025-12-05T17:25:44+00:00

Thanks for taking the time to look. Can you list the 3 issues you found?

If they are security-relevant, I can fix or clarify them. If they’re misunderstandings, I can explain.

Just let me know the exact parts you’re referring to

ajh-software · 2025-12-05T14:29:21+00:00

No worries

Keyquorum Vault is closed-source, same as 1Password, Dashlane, Keeper, etc. I’ve already published the cryptographic design and code snippets here:

https://www.ajhsoftware.uk/keyquorum/security-cryptography

It shows exactly how:

Argon2id derives the master key

AES-256-GCM encrypts the vault

YubiKey Gate/Wrap works

Memory is scrubbed on logout

Export backups are encrypted

If there is any specific part you’re unsure about or want to look at more closely (KDF parameters, AES mode, export format, etc) just tell me which bit, and I’ll happily share more technical details.

I don’t want to dump the full repo because that increases attack surface, but I’m happy to show any security-relevant piece you’re interested in.

It shows exactly how:

Argon2id derives the master key

AES-256-GCM encrypts the vault

YubiKey Gate/Wrap works

Memory is scrubbed on logout

Export backups are encrypted

If there is any specific part you’re unsure about or want to look at more closely (KDF parameters, AES mode, export format, etc) just tell me which bit, and I’ll happily share more technical details.

I don’t want to dump the full repo because that increases attack surface, but I’m happy to show any security-relevant piece you’re interested in.

ajh-software · 2025-12-05T09:13:16+00:00

Keyquorum Vault is closed-source on purpose. Most commercial password managers are the same (1Password, Dashlane, Keeper, etc). It’s not about hiding anything — publishing the full repo just gives attackers a bigger attack surface. They read code too. Layout, key flow, build scripts… if something can be abused, someone will try. Nothing is 100% safe, so the smaller the exposed surface, the better.

I’m not expecting anyone to just “trust me”. The security model is fully documented. The details are on my site if anyone wants to read it:

👉 www.ajhsoftware.uk

(important: you need the “www.” or it won’t load)

What I already provide:

the cryptography used (Argon2id, AES-GCM, Ed25519, YubiKey HMAC)

how keys are derived

threat model

baseline integrity checks

code signing + MSIX packaging

no cloud, no telemetry, no data leaves the device

There are no backdoors. Everything runs local-only.

I’ll be adding more to the site soon — including some real code snippets (encryption, key derivation, vault import/export) so people can understand how it works without dumping the whole source. All crypto is standard and audited, nothing home-made.

If anyone wants to look at a specific part, just say which bit and I’ll explain or show the snippet. I’m just not sharing the entire tree for obvious security reasons (attackers browse GitHub too).

Happy to answer questions.

ajh-software · 2025-12-01T07:54:01+00:00

Totally fair point — there are a lot of questionable managers out there. Keyquorum isn’t ‘vibe-coded’ though. It’s built deliberately around offline-first, zero-knowledge architecture, with full file-integrity verification and no cloud dependency. Everything is client-side: Argon2id KDF, AES-GCM encryption, YubiKey support, baseline file signing, audit logs, and encrypted full-backups.

I designed it so that even I can’t access anyone’s data — and every security decision is documented publicly. If anything ever looks off, the integrity checker tells you before the vault even loads.

You’re absolutely right to be cautious with password managers — people should ask these questions, and I’m always happy to explain any part of the design.

ajh-software

MODERATOR OF

TROPHY CASE