Show HN: OormiPass – free, cross platform and open sourced password manager
Features:
* Stores passwords securely using AES encryption.
* Requires only one master password to access all passwords.
* Stores other useful info like usernames, urls, notes etc.
* Items are categorized neatly into groups, which can be accessed easily by simply clicking their names in the list.
* Users can customize the groups and all items in the group.
* Open URLs directly from Oormi Pass and paste your username and password. Save precious time.
* Functions to auto log out and change master password.
* Hide or show passwords.
* Built in password generator.
* Minimal UI.
* Runs on MS Windows 7 to 10, Linux and Mac OS.
* Code::Blocks 17.12, MinGW, C++11, wxWidgets 3.1.2
* Dependencies: wxWidgets 3.1.2, wxSmith, Crypto++ 5.6.3
Binary for Windows (exe) is available.
[1] https://github.com/oormicreations/OormiPass/blob/d1d2bf5100f...
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.
https://www.cryptopp.com/wiki/RandomNumberGenerator
https://www.cryptopp.com/wiki/Authenticated_Encryption
Also take heed of this note:
> Please take a moment to read Authenticated Encryption and understand why you should prefer to use CCM, GCM, or EAX over other modes, such as CBC or CTR.
from https://www.cryptopp.com/wiki/CFB_Mode
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?
I wanted to pick this sentence out to point out the general most important thing that any project that claims to be security-oriented should have: A documented threat model. You should know exactly what this thing does try to prevent, and what it explicitly does not try to prevent. A lack of one should be taken as a sign that it isn't ready for any use that requires security.
I can copy the encrypted password to another entry that's easier to compromise: E.g. you might be suspicious of a phishing mail targetting your bank account, but are you paying the same attention to a faked message from a random webforum you use? (Or maybe an attacker can hack said forum a lot easier than your bank)
For a more featureful password manager that has gained a browser plugin that matches on URLs, I can now add an entry for my phishing URL to the password manager.
There's a reason some people call this "the cryptographic doom principle".
Bitwarden https://github.com/bitwarden
Runs on anything including mobile platforms and is100% open source.
There's even a free cloud tier available to sync with.
Not trying to bash OormiPass, but other commentators are already finding concerning security issues like a non-secure random.
Yes, the dependency on mssql is a bummer, but it is freely available and is a robust db system. And, as other have pointed out, there are alternate backends you can run if you want to forego support from the vendor.
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.
One problem with your proposal is that for CPA security cuts the security level of the scheme in half. For an n-bit hash about 2^(n/2) operations are required to find a collision, and given a collision you break CPA security.
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.
Not sure why this is downvoted, at first look this seems to solve things similarly to GNU pass except pass makes sharing password stores with teams etc smooth. Because of using GPG rather than straight up asymmetric encryption you get a key management for free.
Additionally crypto implementation seems hit well-designed. This would have been a lot better as a GNU pass client - exact same user experience but they wouldn't have to solve several important problems.
Personally I use qtpass as a GUI manager and passmenu for fetching from clipboard via a keyboard shortcut.
The features I find most important (besides security) in a password manager is integration and portability. If I can't have my passwords easily where I need them (eg: (auto)filled in forms on my (mobile) browser) without resorting to copy/paste I might as well just use GPG encrypted text files.
There are already enough password managers out there that provide organised secure storage for secrets (eg: pass, 1password). To stand out to me you just really need good integration.
What I'm really looking for is something like this, but with SSSS support ( http://point-at-infinity.org/ssss/ ) - I want to host the encrypted db someplace, and hand a group of friends and family subkeys, such that if X of the Y I gave a key to join forces and combine their keys, they can also decrypt my DB.
Useful if I'm dead or in a coma or whatnot.
Does anybody know of one?
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.
And it has burned me a couple of times because it never shows if you unsync or sync had any error.