Ask HN: Why shouldn’t I roll my own password manager?
Hi all! I’m currently working on a personal assistant bot (no 3rd parties involved, self hosted) that uses one SQLite file as its single source of truth. I would like to add password manager functionality to this so I can e.g. ask it to fill out online forms or save registration information. All passwords would be saved to the SQLite database hashed and salted with AES-256 and they’d need a master password (not stored anywhere) to be decrypted.
I know the golden rule is to not roll your own crypto, and I’m thinking this is somewhat adjacent to that. What does a password manager do in terms of security that I haven’t / can’t? Or am I on the right track and all password managers work in this same basic way?
(
13 comments
| 14 points
| on HN
)
What to watch out for? Honestly, you're missing some information regarding encryption - you can't store the passwords hashed and salted (you need to recover them completely) and aes-256 does neither of those operations. So you have to at least do some extra research.
"All passwords would be saved to the SQLite database hashed and salted with AES-256" - AES-256 is not a hash algorithm, its a symmetrical encryption algorithm.
If you "salt and hash" the passwords before you store them, you cannot retrieve the passwords again, you can only confirm that a user provided the same password now as they did when you stored it.
If you're encrypting the passwords using AES-256, you've got the meta problem of securing the encryption/decryption key (and if that's coming from your "master password" you need to ensure that it actually has enough bits of entropy and that it's suitably processed from a password/passphrase into something usable as a 256 bit AES key.
My gut feel from your wording/terminology there is that you're not yet ready to start a project that's intended to secure a collection of important passwords. Perhaps I'm wrong, and you're just using crypto-related terminology in a very loose fashion, but if I were you I'd do some more research and become at least knowledgable enough that you don't write about it as ambiguously at you have here.
A good way to start there might be to learn how the BitWarden handles the password encryption. It's open source, so you can see all the gory details, and it's been third party reviewed, so you can follow along with some of the reviewers complaints and the fixes the project made via their GitHub history.
Note that BitWarden have an interesting comment in their FAQ: "Bitwarden does not write any cryptographic code. Bitwarden only invokes crypto from popular and reputable crypto libraries that are written and maintained by cryptography experts." which is a big positive in my opinion. (Note that using good crypto code incorrectly can still leave them wide open, but it's a way better starting point that rolling any of your own crypto code...)
They also settled on at least a similar set of "buzzwords" as you have: "Your data is sealed with end-to-end AES-256 bit encryption, salted hashing, and PBKDF2 SHA-256." so at least there's some confirmation that you're on the right path :-)
And, in case you have't seen it yet: https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
Your plan is starting out at least sounding like it's compatible with the 2015 "right answers" from ptacek - so _that's_ a good start.
Also it'd be worthwhile investigating how other password manager mobile apps (if you can get the source for them) handle securely storing critical decryption keys in the OS's version of it's secure enclave (if they do). That's a question I have about BitWarden's iOS app that I haven't answered for myself (yet?)
If you use the appropiated hash functions (PBKDF2, bcrypt, scrypt, not "AES-256") you are not rolling "your own crypto".
Hash functions are useless in a password manager; you can't retrieve the password after hashing. That's why you use them for storing passwords on the server side, but a password manager needs to know the password so that it can send it to the server.