How To Safely Store A Password (2010)

Re:How To Safely Store A Password (2010) by ficklepickle on Thursday December 03, 2020 @09:48AM (#25289318)

This argon2 implementation[0] looks good to me. It uses a native module so it should be fast, and I like the look of the API. It returns the salt and params with the hash in one string, so storing and verifying looks real simple. It appears to be maintained. It has TS type declarations, if you are into that sort of thing.

Here is an scrypt just in JS[1]. It will also run in the browser, if you need to hash client side for some reason. On node, it will use the built in crypto api which IIRC is a wrapper around openSSL so perf should be native. I'm not a big fan of the API, you have to concern yourself with buffers and normalization. Maybe that is important for non-latin alphabets? I don't actually know, I'm too anglo-centric.

Then there is good ol bcrypt[2]. Certainly the most mature, it has been around a while. Like [0], it also uses a native module with node-gyp.

All three support async/await so you can avoid blocking the event loop during expensive hashing operations. I should note I haven't really used any of them. I was just curious so I did some googling.

Based on your criteria, I think [0] fits the bill best. Very hard to forget the salt, as it is generated by default and stored with the hash.

I'm always really curious about other people's code, so I hope you don't mind me asking: I typically use a library/framework that handles details like password hashing. That said, sometimes i like to avoid libs and really understand every aspect. Can I inquire about your stack? Are you using express or koa or anything like that?

[0] https://github.com/ranisalt/node-argon2

[1] https://github.com/ricmoo/scrypt-js

[2] https://github.com/kelektiv/node.bcrypt.js

[ Parent | on HN ]

Re:How To Safely Store A Password (2010) by smichel17 on Thursday December 03, 2020 @10:34AM (#25289802)

I'm using express, and currently "good ol' brcrypt" (your [2]) for the reasons I mentioned and because it is battle-tested, as you say. On the "battle-tested" note in particular, I am not confident in my ability to evaluate the trustworthiness and technical competence of most of the libraries out there. And while something like this[0] provides algorithm recommendations that I trust, there are no specific implementations referenced. "Good ol' bcrypt" is widely referenced enough that I feel comfortable using it, and I would also feel comfortable using node's built-in scrypt, except for the shortcomings in its api that you and I have already mentioned (aka "things that I do not want to concern my employer with once my contract is finished").

I think it's fine enough if I stick with bcrypt, and that's what I'm planning to do, but I saw this was on the front page, so I opportunistically made the comment hoping that someone with experience in this area (e.g. tptacek) might see the question and jump in :)

[0] https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

[ Parent | on HN ]