Show HN: OormiPass – free, cross platform and open sourced password manager
54 comments
rand() [1] is not a secure source of randomness. I strongly recommend against using that password manager since it is not secure.
[1] https://github.com/oormicreations/OormiPass/blob/d1d2bf5100f...
[1] https://github.com/oormicreations/OormiPass/blob/d1d2bf5100f...
+1 hope this comment is top.
They use it for salt and password generation: https://github.com/oormicreations/OormiPass/blob/1a6f0b99613...
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
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
[deleted]
All of these top comments remind me of the general adage that encryption and security are really hard, and if you think you know what you're doing you probably don't.
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.
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.
For the authors I recommend reading the following pages very carefully:
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
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
While I have no inspected OP's use of cryptographic primitives (comments seem to indicate that OP has not made proper use of RNGs), do note that authenticated encryption modes, or rather authentication in general, serves a purpose that is not really relevant for a password manager.
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?
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?
> 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.
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 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.
Hear, hear! The concept of documented threat models is far too rarely used. And, to be frank, the threat model needs to be in place before you design the product.
Scenarios where I can tamper with the password database, but not e.g. add a keylogger to your system are of course somewhat limited (although people love to put the database in sync services like Dropbox) Not just the passwords, the bigger data structure should be authenticated. Some possible scenarios:
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.
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.
As a principle secure things should pay attention to details and follow best practice. For me,I'm more concerned about lack of kdf and rng.
But it all depends on how the program treats the data after decryption and how your password db is stored and transported. You have to also keep in mind that users keep other secrets as well in a password manager,not just passwords. You're giving the public a secure secret storage mechanism,you should follow best practices because you don't know exactly what type of attackers your users face ,what type of specific data/creds they store in it or how they transport it.
You need to be more careful with your reasoning. It's not always the case that a MAC simply prevents "replacing, trashing, or performing zero-knowledge modifications" on your data. It can be the case that you cannot retain confidentiality without integrity; MACs prevent chosen-ciphertext attacks.
While correct that authentication can prevent chosen-ciphertext, I do not see how such an attack could be relevant against an offline password manager. I ignored it for that reason.
There is also the Efail pattern of attacks, where malleable ciphertext is used to inject active controlled plaintext (HTML tags, different URLs, etc) that exfiltrate the rest of plaintext. Can you rule that out as well?
There's a reason some people call this "the cryptographic doom principle".
There's a reason some people call this "the cryptographic doom principle".
Corruption detection is the main one, but it is indeed not a security issue
Indeed, and if corruption detection is your goal, a checksum is the proper solution. Authentication is an expensive and roundabout way to do simple corruption detection.
Isn't this wheel reinvention?
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.
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.
Even more importantly, BitWarden has passed a third party security audit and published its results: https://blog.bitwarden.com/bitwarden-completes-third-party-s...
Not trying to bash OormiPass, but other commentators are already finding concerning security issues like a non-secure random.
Not trying to bash OormiPass, but other commentators are already finding concerning security issues like a non-secure random.
requires mssql if you want to self host... Meh, keepassx still better.
Check out bitwarden_rs for an alternative backend that's easier to host.
While keepassx is a great tool, Bitwarden is a much more capable product which solves many more use cases than the single device/single user one.
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.
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.
While I can believe that multi-user with Keepass would be problematic to say the least, multi-device is not. I've been using it for years with several devices syncing via my own NextCloud instance.
nobody should ever try to make a thing if a thing that does the same thing already exists!
They should try, but maybe if they make the most common RNG mistakes they aren't suited for reinventing this particular wheel. There are many issues with the RNG and cryptography methods if you read the other comments.
I have not confirmed it, because building it on MacOS seems to be a bit of a pain, but by glancing at the source code it looks like this encrypts passwords separately but with the same IV, trivially breaking security (even at rest).
I'm aware of chosen plaintext attacks against a reused IV, but at rest the attacker is just an observer.
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.
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.
The code uses CFB mode, so fixing the IV results in a constant first block, which gets XOR'd with the first plaintext blocks to make the first ciphertext blocks. So knowing one plaintext gives you access to all first plaintext blocks.
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.
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.
Pass is literally all you need: https://www.passwordstore.org/
My biggest concern with pass (even after keeping the password store itself on a Veracrypt volume) is that - authorized or not - typing the `pass` command prints a nice, pretty list of every website/password title in the store.
That makes me really uneasy.
I considered changing them all to random strings, but that would make it difficult for me to find the password I need - defeating the purpose.
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.
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.
You could put the pass directory on an encrypted filesystem.
I would rather not use the command line to manage my passwords and not everyone can use the command line.
There are a variety of clients for several platforms (desktop and mobile apps, browser extensions, desktop environment integrations). You can use pass without a single console line.
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.
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.
Interested in how pass can be used without the command line?
They have some links on their front-page (linked in the top comment): https://www.passwordstore.org/#other
Personally I use qtpass as a GUI manager and passmenu for fetching from clipboard via a keyboard shortcut.
Personally I use qtpass as a GUI manager and passmenu for fetching from clipboard via a keyboard shortcut.
I'm using `pass` for years now and it's perfect. On Android there is the Password Store app which integrates with the OpenPGP app, it's amazing :).
Agreed pass is fantastic. It's built on top of tools such as gpg and git. It's simple and easy to extend or build clients for.
What differences does this have with KeepassXC?
How is this different than Bitwarden?
From what I read this is a offline (in device) password manager, as BitWarden is a service (online).
Yep, BitWarden can't handle being offline (storing passwords for ex.).
Bitwarden handles being offline just fine. Like you need to go online eventually if you want to sync your changes but it's not like you need internet to manage your vault.
It lost a password for me when I were offline and pressed "Yes, save password" on the bar dialogue, don't discount the possibility of bugs existing.
> Open URLs directly from Oormi Pass and paste your username and password. Save precious time.
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.
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.
Feels like this adds nothing compared to various keepass (clone) offerings.
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?
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?
I imagine making something like that would be fairly easy as an Keepass plugin.
perhaps Hashicorp Vault fits your requirement? it is not a trivial piece of software to host, but it has the multi-key feature that you need. otherwise, it's mostly a key-value store.
For my curiosity, what makes vault non-trivial to host? I readily admit that it is non-trivial to run inside kubernetes because of the unseal mechanism, but as for just run "vault on this machine" it is my experience that it is fantastically easy.
Thank you all for your comments and for pointing out the bugs. Hopefully, the coming versions will be more secure.
This was a good learning exercise.
Contributions are most welcome (Especially on authentication issue, the rand issue and IV issue seems to be fixable).
I realize this isn't a solution for everyone, but my password management is
pw.sh
gpg -c ~/passwords.gpg | grep "$1"
pass from zx2c4 is this but much more refined, if you ever get tempted to add "a couple more features" to your hack I recommend just using pass instead.
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.
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.
Needs a way to sync to cloud storage, having all your files locally is a good way to lose them all if something happens let data corruption.
I'm using enpass. Fantastic, cheap and runs on Win/Mac/Linux and iOS/Android.
Also syncs to your cloud of choice.
Enpass has many nice features. The PIN lock, the cloud drive sync (not centralized but still easy) but damn version 6 has been breaking things in so many ways that it's disappointing. It's so hard to find things and random things don't work between Mac/Linux. I wish people would go for look so much.
And it has burned me a couple of times because it never shows if you unsync or sync had any error.
And it has burned me a couple of times because it never shows if you unsync or sync had any error.
another Enpass user here. it works very well for me on Mac and Android.
[deleted]
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.