For the third point, why not just hash the password with SHA256 first? Sorry, I didn't look at the code, just going off of the described issue. If you have an arbitrarily sized input and you want a fixed 32 byte output, that seems by far the simplest way.
A single round of SHA256 used as a master password is definitely NOT what you "should" do.
---
(I apologize in advance. I don't typically make comments like this on HN but I feel it really is warranted here.)
Key Derivative Functions (KDFs) have already been mentioned here in the comments.
By not using one -- and, perhaps more importantly, by 1) not even understanding why you should use one and 2) thinking that one round of SHA256 is what you "should" do -- well, to be blunt, your project just screams out "hacked together piece of shit made by someone who has absolutely zero business whatsoever making a password manager".
---
"Show HN"'s are to get feedback. As it stands, your project should not be used -- by pretty much anyone! It doesn't have to stay that way, though. Please take some of the good advice you've gotten in the comments here and improve your project so that it can safely be used.
To anyone else who reads this I’ve made several changes to the code based on feedback presented in previous comments so far including using PBKDF2 for key derivation (actually well before jlgaddis’ comment here was posted which is unfortunate, sort of screams “I’m lazy and before I confirm I’m going to blast this peion publically because it’ll make my Sunday a little bit better than it already was”).
Nonetheless I appreciate the last bullet as I definitely post to Show HN to learn and get better as a developer, and certainly expect nothing less than to receive a few “fuck your shitty project”s along the way :)
(This is my second attempt at "constructive criticism"; my previous attempt failed spectacularly. Sorry this ended up being such long-winded but after rushing to post my previous, off-the-cuff comment, I wanted to avoid doing that again.)
---
> ... I’ve made several changes to the code ... including using PBKDF2 ... actually well before jlgaddis’ comment here was posted ...
Yes, you're right. That's my fault, mostly because of how I tend to browse HN.
I had opened both the GitHub repo and the discussion thread in their own new tabs. I actually had browsed through the repo and briefly looked over some of your code although I will certainly admit that I didn't conduct an extensive, in depth review of it! In fact, I was still reading through it when SWMBO suddenly appeared in front of me, informed me of an urgent mission, and instructed me to begin working on it at once. By that point, I had already "seen enough" so I just closed the tab, tossed the iPad down on the couch, and headed out on my new mission.
When I picked up the iPad again a couple hours later, Safari reloaded the tab that was open (this discussion thread), I began reading the comments, and, after reading your comments upthread, felt compelled to leave one of my own.
---
Anyways...
The point that I had intended to make was that, sometimes, a little knowledge (or, alternatively, "a lot of ignorance") can be a very dangerous thing. I'm gonna digress real quick but I'll come right back to that.
I didn't intend for my comment to be a personal attack on you and I'm sorry that it came across that way. There really was a legitimate point that I was trying to get at; the "bigger picture" that I was attempting to paint, if you will.
I can, however, be (in the words of an old co-worker and more than one student) a bit of a "security nazi" at times. Unfortunately, this was one of them. My knee-jerk reaction to someone "doing something stupid" was a hastily written comment which resulted in a poor choice of words that failed to paint that "bigger picture".
First, it's certainly a good thing that you took the direct advice you were given (i.e., "use a KDF!") and quickly improved upon your new project. Props for that. Presumably, tt's now much more secure as a result (I haven't actually looked at your changes but I'll give you the benefit of the doubt)!
Now, back to that "a little knowledge can be a very dangerous thing" thing.
When you start getting into security-related areas, simple mistakes can have a devastating, outsized, and lasting impact. There's no doubt that a password manager provides huge benefits -- if it's designed and implemented correctly! The only thing that I can think of that's worse than a complete dumpster fire of a password manager is a complete dumpster fire of a password manager that 1) the user assumes is working as expected, 2) the user trusts with their personal/private data, and 3) lulls the user into a false sense of security -- since they might actually be worse off (i.e., "less safe") than they were before!
Ultimately, the "real problem" is that you were developing a tool that claimed to "securely" store secrets without actually knowing how to "securely" store secrets at all! There are several well-tested, industry-standard algorithms designed to do exactly this -- yet, for whatever reason, you instead devised something that sounded okay and seemed like it might kinda sorta work. It quickly became clear from reading your other comments that you had good intentions; it was simply ignorance, not malice.
Unfortunately, when it comes to security-related stuff, it doesn't really matter if it's ignorance or malice -- the end result is the same. It's like handing a loaded AR-15 to someone who has never handled a gun before and telling them to have fun, or letting a little kid set off the fireworks on the Fourth of July: you may get lucky and nothing bad happens; eventually, though, someone's probably going to end up getting hurt and/or missing a few fingers!
---
> * ... I’m going to blast this peion [sic] publically [sic] because it’ll make my Sunday a little bit better ...*
To be clear, I wasn't trying to be condescending or imply that you're a "peion", or stupid, or a shitty developer, or anything like that. If you're creating something that has major security implications, however, you really do need to know what you're doing. If it makes you feel any better, I'm certainly not qualified to develop a password manager capable of securely storing passwords (and I wrote my first program sometime in the late 80's)! That's not to say you won't ever be capable of creating one, of course -- but, if you're going to be developing software that has security implications (especially for other people!) if you get it wrong, please make sure you learn how to do it right.
Completely fair points, thanks for taking the time to clarify your intent and meaning in your previous comments. I also understand and get the points about ignorance vs malice and it not mattering which is present wrt a security tool to be used by others. I admit I’m not a cryptography “expert” in that I couldn’t regurgitate low level details for any industry standard algo, although I do like the think so know what should be used and when (for the most part).
If nothing else I’m smarter and know a little more about what I didn’t know (and still don’t) which I find a ton of value in. Hopefully I’m slowly ridding the world of my contribution to the “ignorance” category you mention above which I admit to have been in wrt developing a secure password manager, but either way I enjoyed learning along the way.
Cool! Sounds like a good idea. A key stretcher is probably a good idea too if you haven't done so. Given that this is local only, you can go pretty nuts on the key stretching. For example, on a server I'd say >100K rounds of PBKDF2. For local, you could do 1B.