3 ms·

Ask HN: Why shouldn’t I roll my own password manager?

14 points by nexuist 7y ago

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?

wmf 7y ago
At the very least I would hope open source password managers have some design docs that you could look at.
viraptor 7y ago
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 7y ago
  bitwarden_rs might be a good starting point
bigiain 7y ago
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-answers.html 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.
- cocoa19 7y ago
  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 7y ago
    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 7y ago
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)
segmondy 7y ago
you can role your own.
quickthrower2 7y ago
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.
barry27 7y ago
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.
atnbueno 7y ago
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 7y ago
  > 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.
decasteve 7y ago
Have you thought of building it on top of pass: https://www.passwordstore.org/ https://www.passwordstore.org/