Q Vault: An open source secret manager

github logo ・1 min read

Github: https://github.com/Q-Vault/qvault
Website (under construction): https:qvault.io

Q Vault is a new open source password manager built using electron, javascript, and vuejs. The goal was to create an open source password manager that:

  1. Is user friendly

  2. Secure enough to store cryptocurrency

  3. Has built-in optional cloud storage backups

  4. Can be used offline

  5. Can require a physical key for extra security (Plastic Cards with QR Code used for dual encryption)

twitter logo DISCUSS (21)
markdown guide
 
 

The salt isn't security critical in our use case because the result of the hash isn't stored.

 
  1. Yes it is the perfect excuse to reuse salts because the salt is basically irrelevant.
  2. The crypto library requires a salt so we simply supply one.

Again, we hand chose these algorithms for a reason. We don't want to use a higher level library and lose control. The node/crypto implementation requires a salt so we supply one. It doesn't matter that it never changes or that it is public knowledge.

Oh okay, that makes sense now. I thought you were using a salt legitimately.

Yeah, it is kinda a strange use case haha

 

What library/libraries does it use for cryptography?

 
 

I'd avoid it. It seems really low level from reading some of your source code. Check out a Libsodium port for Node.js.

Using low-level cryptography libraries make it easy to screw up.

Hmm? It's just hashing and ciphering. Adding an extra dependency in the middle for no reason is scarier to me.

Libsodium is a cryptography library that's easy to use. You should be using that instead of what you're doing.

I disagree. I understand what I'm doing, I'm well enough versed in cryptography to prefer the actual crypto library than training wheels.

Libsodium isn't "training wheels". It's a production ready solution that most people should be using.

I'm sure we COULD use it. But really its a preference thing. I want to use the SCRYPT hashing alorithm. And I want AES-256 GCM. Why not just use them directly from a trusted source?

Okay. It makes sense. Why do you want AES-256 in GCM mode? And why Scrypt?

From a high level GCM is considered more secure than CBC. Especially at lower resolutions. Good link: crypto.stackexchange.com/questions...

I like scrypt for our use case because we are simply trying to make it hard to brute force access. Scrypt requires high powered computation AND memory in order to continue guessing keys.

 

2) It's debatable.

3) It is not the password manager's job to sync files. Let the user deal with that. Save it to a file and call it that. Stop trying to do everything. Do one thing, and do it well.

 

2) definitely debatable. Security is a scale.

3) It just saves to a file by default. We like that it has the ability to sync to the cloud backend within the app (optionally) and handle conflicts between local and server.

 

I guess it's fine to have a built-in syncing feature, but it divides your attention. You should be focusing on securing the secrets, rather than syncing files and checking for conflicts.

Users could use NextCloud, DropBox, Syncthing, etc. There are already existing solutions. Just sync the file and let those solutions handle conflicts.

Yup. And they can totally do that. Don't enable the sync to cloud option and just backup your own files. easy as pie.

Classic DEV Post from Jan 13

Why is Linux Not More Popular on the Desktop?

Picture taken from wikipedia. There are issues when it comes to Linux being mo...

Lane Wagner profile image
Golang and javascript dev interested in distributed systems and cryptography