Hacker News Reader

Comment by Straw | Hacker News Reader

Bcrypt doesn't have memory-hardness, so has high susceptibility to ASIC attacks. In particular, it incurs the same or lower cost factor on the attacker than the user.

More recent designs such as scrypt and Argon2 force high memory usage as well as computation time, incurring little cost on the users but making ASIC and GPU attacks significantly less cost-effective.

Of course, any of these will still give better protection than plain cryptographic hashes.

View on HN

In general it is is not true that Argon2 should be recommended over bcrypt. Even even some of the people on the experts panel for the PHC (where Argon2 won) won’t recommend Argon2 over Bcrypt: https://twitter.com/TerahashCorp/status/1155129705034653698

Looks like for the typical case (~200ms calculating the hash) bcrypt beats argon2. I guess that’s what I understand from those discussions, I’m not an expert by any means. It is related with cache hardness: https://twitter.com/Sc00bzT/status/1149963675069026304

Wow. Never heard that before. Would love a proper article on that. I wonder how scrypt holds up

I am not a security expert, but this looks pretty useful: https://security.stackexchange.com/questions/193351/in-2018-...

And that Twitter link (https://twitter.com/TerahashCorp/status/1155129705034653698) leads here: https://www.password-hashing.net/ ... but, on that website, I could not find an explanation about why to use argon2 over bcrypt.

Interesting, I hadn't seen this before. I find it hard to believe, as Argon2 does psuedorandom access over a large array. As soon as this array gets larger than the local GPU cache (much smaller than CPU cache), we should get pretty good protection. What have I missed?

In particular, in terms of ASIC attacks, bcrypt and other non-memory-hard KDFs have extremely efficient implementations. Silicon is cheap, computation is cheap, memory access is extremely expensive- both in terms of time and power usage.

Is there any scrypt or argon2 implementation for nodejs that has as nice an api surface as the bcrypt package? Specifically, it will generate a salt for you (included at the beginning of the generated hash). This has the great properties of: can't forget to use or store the salt; use a weak salt; or forget to use the time-safe compare function. I want to minimize the number of footguns available to the person coming after me, who I suspect will not do the same depth of research and understanding before making changes as I have when setting this system up.

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

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...

Yes, scrypt-kdf works great:

    const scryptParams = { logN: 15, r: 8, p: 1 };
    async function hashPassword(password: string): Promise<string> {
    const password_hash: Buffer = await scrypt.kdf(password, scryptParams);
    return password_hash.toString("base64");
    }
    async function verifyPassword(hash, password): Promise<boolean> {
        return await scrypt.verify(Buffer.from(hash, "base64"), password);
    }

Is scrypt actually recommended? When I think of scrypt, I think of the Litecoin and the numerous "altcoins" that use scrypt that were forked from Litecoin in late 2013/early 2014.

I know that Litecoin used scrypt to harden it against GPU/ASIC mining, but GPU/ASIC miners ended up coming out anyways. With this in mind, is scrypt actually a better option than bcrypt?

Came here to say this. I'm guessing we are both just the unlucky saps whom the algorithm chose to screen new submissions.

Surely HN doesn't do that... Pardon me if I missed your joke. More likely explanation is that CA isn't awake yet!

Reply on news.ycombinator.com