
Ask HN: Why shouldn’t I roll my own password manager? - nexuist
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.<p>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 &#x2F; can’t? Or am I on the right track and all password managers work in this same basic way?
======
viraptor
Instead of doing everything from scratch, you could support bitwarden API on
server side and reuse all the existing clients. Or at least look at how they
do it before you start your own.

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.

~~~
jazoom
bitwarden_rs might be a good starting point

------
decasteve
Have you thought of building it on top of pass:
[https://www.passwordstore.org/](https://www.passwordstore.org/)

------
bigiain
A few comments:

"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...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
answers.html)

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.

~~~
cocoa19
Reading keepass documentation, you my might also want to consider protecting
sensitive data in memory. See keepass Process Memory Protection.
[https://keepass.info/help/base/security.html#secmemprot](https://keepass.info/help/base/security.html#secmemprot)

~~~
bigiain
Good advice.

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?)

------
stallmanite
Any plans to share the program when it’s done? It sounds like something I’ve
wanted to build but never gotten around to. (My idea was an unholy TiddlyWiki
/ sqlite hybrid so the aesthetics of yours will probably be superior)

------
quickthrower2
How it copies/pastes/keys passwords might be a concern. Doe it keep them on
the clipboard? How long does it stay open? Have a play with KeePass to get a
feel for those.

------
atnbueno
Do it. You'll learn a lot. But afterwards you'll switch to an already existing
password manager. Mainly because you can't think of everything, and they have
years of experience (and frequently external audits). As other commenters have
said, not everything is the storage of data.

If you use the appropiated hash functions (PBKDF2, bcrypt, scrypt, not
"AES-256") you are not rolling "your own crypto".

~~~
brianush1
> _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.

------
wmf
At the very least I would hope open source password managers have some design
docs that you could look at.

------
segmondy
you can role your own.

------
barry27
You should definitely roll your own, to be certain that the government is not
stealing your secrets. They can send the information to computers on the
internets now without your knowledge.

