Show HN: OormiPass – free, cross platform and open sourced password manager

I do love the fact that it uses git though. This is huge when you have it on multiple devices and might, say, add a new password from your phone.

That is, I do not find an adversary replacing, trashing, or performing zero-knowledge modifications on my credentials to be an attack vector that has any importance. What would the adversary gain from tampering with passwords (which authentication would protect against) without the ability to read them (which encryption takes care of)? It would mean that I lose access to, say, my online bank account, but this is just as well done by deleting the database without tampering.

My only interest would appear to be to maintain secrecy of my password database so that an adversary does not obtain my access to my passwords, which does not require authentication.

That does not mean that using AES-GCM would hurt, but it also wouldn't really add any notable benefits here. Unless someone else can think of a scenario where authentication would be needed?

Also,

> The master password is not stored. An SHA256 salted hash is stored instead.

Have they heard of scrypt or argon2? And they're not using a KDF(!!!!!!) With sha256.

Dear Authors,if you ever read this,please look at: https://cryptopp.com/wiki/Key_Derivation_Function

And

https://cryptopp.com/wiki/RandomNumberGenerator

I don't want to be too harsh for a ShowHN, but even if the authors fixed the several bugs that have already been reported here, it's clear they don't have a foundational enough understanding of cryptography and security to be writing a password manager. I would suggest they spend more time understanding the basics first.

Offhand, the only problem I see with a fixed IV for string storage encryption is that if two passwords match in the first kB bits, were B is the AES blocksize and k is a positive integer, and assuming CBC mode, the attacker can see this.

Are there worse holes open to someone who is just observing at rest data?

That reminds me of something I've wondered about. How about AES in CBC mode with a fixed IV, but the plaintext is prepended with a hash of the entire message first, using a hash of at least the size of the AES block?

In effect, if the hash output is the size of one AES block, that makes the hash encrypted with the key using the fixed IV be the IV for the encryption of the plaintext.

That should effectively give each plaintext its own IV derived from its hash and the key, but conveniently stores this in the output string so you don't have to have separate IV storage. This could be convenient in applications where you adding encryption to something existing, such as changing a DB to hold encrypted values instead of plaintext values in certain columns, but where you are reluctant to add new fields, such as adding a column for the IVs.

For some storage applications, you want to support checking if a given plaintext is already stored and return the index of that prior instance in that case rather than store a new instance, so if you use random IVs then you need to separately store a hash of each item, and if that is not encrypted that could be a vulnerability if someone stole a copy of the DB if the plaintexts are small (like credit card numbers).

The prepend the hash to the plaintext and use a fixed IV on that provides the reproducibility for duplicate checking, without obviously exposing the hash to someone who steals the DB, while effectively encrypting the actual plaintext using a pseudorandom IV derived from the AES key and the hash.

But I've not seen it used or described, so don't know if it is an OK approach.

And it has burned me a couple of times because it never shows if you unsync or sync had any error.

Not trying to bash OormiPass, but other commentators are already finding concerning security issues like a non-secure random.

e.g. pass also knows how to generate passwords and how to remember related info like which email address is associated with a particular password.