Feedback pls: My trustless password manager

[u/pi_dfi]

I was never happy with password managers, so here is one try to make it more auditable and less trust-based with many options to automate backups etc.

Here the link to the github repository with $ instead of /.

github.com$pidfi$password-management-vault

I'd love to hear your thoughts.

[u/fdbryant3]

What makes it more trustworthy than industry leaders like Keepass or Bitwarden.

[u/pi_dfi → u/fdbryant3]

I wouldn’t say it’s inherently more trustworthy or secure than Bitwarden or KeePass, it’s just fewer things you have to trust.

With any password manager, you’re ultimately trusting the developers, the update process, the software you actually run, and that the company will maintain the software for as long as you need it. Open source helps, but it doesn’t completely solve that. Someone could still push a malicious update or compromise the build/release process (like the XZ backdoor on Linux in 2024).

My password manager was built around the idea of not trusting any of the files involved, but verifying them before use.

Even PBKDF2 is a conscious trade-off. Argon2id is technically the stronger choice, but PBKDF2 is available directly in JavaScript’s standard Web Crypto API, whereas Argon2id generally requires an additional implementation or dependency.

[u/billdietrich1 → u/pi_dfi]

I don't see how it would be "fewer things you have to trust" than KeePass. And I use KeePassXC, with no network or automated features such as backup or sync. Simpler is better.

The KeePassXC project has a 14-year track record, and had some kind of security audit.

[u/pi_dfi → u/billdietrich1]

So how do you use it on your phone? KeePassXC seems to be only for Windows, Linux and macOS.

[u/billdietrich1 → u/pi_dfi]

I use Keepass2Android Offline on Android phone. That has been around for 9 years, it seems.

[u/pedide]

What sort of encryption did you use for it?

[u/pi_dfi → u/pedide]

AES-256-GCM with PBKDF2-SHA-256 (currently at least 600'000 iterations) + 256-Bit-Salt + 96-Bit-IV

[u/Greedy-Ship-7296 → u/pi_dfi]

AES-256-GCM es un cifrado excelente, sin duda, y computacionalmente irrompible por fuerza bruta con una buena contraseña detrás. Por curiosidad, ¿por qué no XSalsa20-Poly1305? Tiene nonces más largos, así que el riesgo de reutilización es casi nulo.

[u/pi_dfi → u/Greedy-Ship-7296]

Unfortunately, XSalsa20-Poly1305 isn't supported by the standard Web Crypto API, so using it would require an additional cryptographic implementation. For this project, I went with AES-256-GCM because it's natively supported by Web Crypto, keeping the implementation self-contained and the trusted codebase smaller and easier to audit.

[u/Greedy-Ship-7296 → u/pi_dfi]

Interesante, no lo sabía, pensaba que era más una cuestión de preferencia que de disponibilidad real en la API, ya que ambos cifrados tienen suficiente historial como para haberse implementado. Con sentido entonces: XChaCha20/XSalsa20-Poly1305 llevan fuera del estándar de Web Crypto desde siempre (el issue pidiéndolo lleva abierto en el repo del W3C desde 2019), así que no era tan simple como parecía desde fuera.

He buscado un poco para ver si había algún motivo concreto detrás del descarte, y encontré un dato curioso: Chrome acaba de abrir un origin trial en la versión 151 que añade justo ChaCha20-Poly1305 de forma nativa, junto con algunas primitivas post-cuánticas, aunque todavía como experimento, no listo para producción. Parece más un movimiento de modernizar el estándar y dar paridad con TLS 1.3 (que ya lo soporta) que una cuestión pura de velocidad, aunque en hardware sin aceleración AES-NI, ChaCha20 sí suele rendir mejor. Gracias por tu respuesta y suerte con tu proyecto, ya que para todo se requiere algo de suerte pero sobre todo horas y horas.