4 ms·

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

by Straw 6y ago

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.

indolering 6y ago
Came here to say this. I'm guessing we are both just the unlucky saps whom the algorithm chose to screen new submissions.
- foobarbecue 6y ago
  Surely HN doesn't do that... Pardon me if I missed your joke. More likely explanation is that CA isn't awake yet!
smichel17 6y ago
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.
- ficklepickle 6y ago
  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 https://github.com/ranisalt/node-argon2 [1] https://github.com/ricmoo/scrypt-js https://github.com/ricmoo/scrypt-js [2] https://github.com/kelektiv/node.bcrypt.js https://github.com/kelektiv/node.bcrypt.js
  - smichel17 6y ago
    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-answers.html#password-handling https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
- phiresky 6y ago
  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); }
jorge_leria 6y ago
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 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 https://twitter.com/Sc00bzT/status/1149963675069026304
- IAmLiterallyAB 6y ago
  Wow. Never heard that before. Would love a proper article on that. I wonder how scrypt holds up
  - kevinarpe 6y ago
    I am not a security expert, but this looks pretty useful: https://security.stackexchange.com/questions/193351/in-2018-what-is-the-recommended-hash-to-store-passwords-bcrypt-scrypt-argon2 https://security.stackexchange.com/questions/193351/in-2018-... And that Twitter link (https://twitter.com/TerahashCorp/status/1155129705034653698 https://twitter.com/TerahashCorp/status/1155129705034653698) leads here: https://www.password-hashing.net/ https://www.password-hashing.net/ ... but, on that website, I could not find an explanation about why to use argon2 over bcrypt.
- Straw 6y ago
  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.
Sohcahtoa82 6y ago
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?

by Straw 6y ago

indolering 6y ago

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

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

smichel17 6y ago

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.

ficklepickle 6y ago
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 https://github.com/ranisalt/node-argon2 [1] https://github.com/ricmoo/scrypt-js https://github.com/ricmoo/scrypt-js [2] https://github.com/kelektiv/node.bcrypt.js https://github.com/kelektiv/node.bcrypt.js
- smichel17 6y ago
  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-answers.html#password-handling https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
phiresky 6y ago
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); }

jorge_leria 6y ago

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 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 https://twitter.com/Sc00bzT/status/1149963675069026304

IAmLiterallyAB 6y ago
Wow. Never heard that before. Would love a proper article on that. I wonder how scrypt holds up
- kevinarpe 6y ago
  I am not a security expert, but this looks pretty useful: https://security.stackexchange.com/questions/193351/in-2018-what-is-the-recommended-hash-to-store-passwords-bcrypt-scrypt-argon2 https://security.stackexchange.com/questions/193351/in-2018-... And that Twitter link (https://twitter.com/TerahashCorp/status/1155129705034653698 https://twitter.com/TerahashCorp/status/1155129705034653698) leads here: https://www.password-hashing.net/ https://www.password-hashing.net/ ... but, on that website, I could not find an explanation about why to use argon2 over bcrypt.
Straw 6y ago
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.

Sohcahtoa82 6y ago

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?