Flood: bcrypt via node-gyp fails to compile on FreeBSD

[randomnonsense]

As explained here: https://github.com/jfurrow/flood/commit/d38ab8525275771e7ef52667e16403a36b836938

Which means most recent commits break flood, which was so far working perfectly fine. Thanks.

[randomnonsense]

Can a workaround for this be dropping encryption completely? And make it user select-able at installing via 'npm install' for a custom non-blowfish deployment? I run everything in a secure environment anyway. I do "understand the risks".

Edit: Or reverting back to the previous bcrypt. Or using another crypto module. AES?

[jfurrow]

@randomnonsense I'm sorry that the commit is breaking for you. In the commit you referenced, I switched to this bcrypt module because it's actively maintained and well-trusted. I think you can agree this is good for the majority of users, especially those — like myself — who are not security experts.

Can you please look at these similar issues found on the Bcrypt module's repo? https://github.com/kelektiv/node.bcrypt.js/issues?utf8=%E2%9C%93&q=is%3Aissue%20freebsd In all of those issues, the users were able to solve the problem. There are no active issues reporting builds failing on FreeBSD, to my knowledge.

If that doesn't work, please file an issue in that repository, and in the meantime, consider using
@wonderfall's fantastic Dockerfile (it should replace the one in the Flood repo, honestly).

[randomnonsense]

@randomnonsense I'm sorry that the commit is breaking for you. In the commit you referenced, I switched to this bcrypt module because it's actively maintained and well-trusted. I think you can agree this is good for the majority of users, especially those — like myself — who are not security experts.

Sorry, but I can't agree at all. It also doesn't seem you actually reviewed the problem. This feature was removed from FreeBSD's ABI on purpose as it was clearly deprecated. Consider https://reviews.llvm.org/D21329 which explains what's been done. So the change you made is not a change making a step forward, but backward. How is that "good for the majority of users" if Flood now uses a library based on deprecated premises?

Sadly this means no FreeBSD 11+ user will be able to use Flood. And that's that. FreeBSD is not a trivial system with irrelevant userbase.

Can you think of any way to work around this? Did you perhaps consider replacing blowfish with AES? Now, that would be an advancement.

[jfurrow]

@randomnonsense I reviewed the problem as thoroughly as I thought necessary to triage your issue. The module introduced is well-known and trusted. No other NPM module is as well known or well trusted, that I am aware of. If you are aware of one, you are welcome to suggest its usage.

[jfurrow]

I should add that I don't mean to trivialize the FreeBSD userbase. Ideally, Flood would work in every environment, without flaws. But that's not realistic for a project like this. I am a single person working in my free time.

In the future I'll suggest that everyone run Flood in a Docker container where the environment is 100% reproducible, no matter which host machine chooses to run it.

From what I can tell, you are capable of installing this dependency, with a little legwork on your end. But you are refusing to do this.

[randomnonsense]

I understand what you're trying to say, but your point is a miss in this case. It matters little if something is "trusted and well-known" if it's broken. Is it? Yes, it is. It features deprecated constructors.

This is not about my skill or willingness to adjust to anything, but about you being reasonable or not. Leaving bcrypt's code quality aside, you made a choice to use a module which is problematic. I reported the problem which is apparent. Is it? It is. Instead of acknowledging it, especially as you are the head honcho and flood's guru here, you're now set to argue your case "defending" your choice, which was not reasonable, like it would be so. Let's face it.

You made a design choice. You chose the module. There's an obvious problem. Own it instead of shunning it.

[randomnonsense]

I've opened a ticket at bcrypt. https://github.com/kelektiv/node.bcrypt.js/issues/552

I play a bit of a dummy but it's their problem after all. Let's see what happens.

[randomnonsense]

What about using AES instead of blowish? I am not a JS programmer (and I swear, I don't want to be), but this looks straight-forward, same level of complexity as your code handling bcrypt:
http://lollyrock.com/articles/nodejs-encryption/

[randomnonsense]

Or keep passwords as SHA512 hashes, http://lollyrock.com/articles/nodejs-sha512/

Solutions are plenty. Just be reasonably open minded.

[recrsn]

I can _confirm_ that flood installs just fine in FreeBSD 11

[noraj]

TL;DR: please use Argon2 with libsodium for nodejs

Blowfish is a deprecated cipher, openssh removed support for it in last release because there are some well known collision attacks.
Bcrypt is more robust than simple blowfish and is still acceptable for password hashing but it begins to be quite old and is based on blowfish which is outdated.
The last Password Hashing Competition winner is Argon2, this is the best secure way to store your password.

Please stop using bcrypt because blowfish support will be removed everywhere in the future. Don't use SHA-512 raw it's no designed for password storage an is optimized for GPU.

SHA2 (sha-256, sha-512), SHA3 (black2, keccak) are optimized to be fast but Bcrypt, Scrypt, PBKDF2, Argon2 are designed to be slow in order to slow attacker for password hashing/storage!

It's not up to date for algorithm to use be here are some good practices : Salted Password Hashing - Doing it Right

please refer to this : How to Safely Store Your Users' Passwords in 2016, here anchor for nodejs.

I'm not a crypto expert just a cybersecurity engineer but my knowledge tell me that using the last winner of PHC is the best you can do.

PS : may be open a new issue to switch form bcrypt to argon2

[SanPilot]

@noraj1337, using a shiny new hashing algorithm is likely not a good idea. The general recommendation when it comes to security is to use a function that has been in use for a long time and is still considered secure. I'm this respect, bcrypt is considered ideal for password storage.

[randomnonsense]

Flood doesn't have to be cryptographically tough. It needs simply to protect passwords _somehow._ Since in most cases it will be run as a user process from user home directory, it is automatically protected this way anyway. Unless somebody really forgets to set a proper permission mask.

So the question about Flood using "some cryptography" is not about actual mission critical security, but about its universality. rtorrent is fully universal. nodejs is universal. flood should be too. a plug and play thing. Or not? If not, then why not?

@jfurrow chose a module which is problematic. I pointed that out. There are many convenience ways to handle passwords here, instead of it. This is plainly obvious. The most simple are SHA512 hashes, which are already more than enough.

[randomnonsense]

I can confirm that flood installs just fine in FreeBSD 11

Unsing node 8.6.0 with npm 5.4.2, both current stable installed via the package manager, bcrypt doesn't compile. As originally reported.

[randomnonsense]

Managed to get it working. The original report still stands, though. With out of the box package installed node 8.6.0 and npm 5.4.2 bcrypt doesn't compile.

[jfurrow]

I'm reopening this for more visibility. @randomnonsense I probably closed this too eagerly.

Right now I'm leaning towards @noraj1337's suggestion. Other security-savvy folks I consulted with suggested Argon2 as well.

[randomnonsense]

Thanks, appreciated.

[dcousens]

This only protects a users password privacy...
It isn't like the users torrents details are protected against a data breach.

@noraj1337 points out the facts RE best practice in password privacy in the event of breach, if Argon2 _works_, then lets!

[noraj]

TL;DR : PHD said Argon2, just use it.

@SanPilot Of course I read that, bcrypt is better than PBKDF2, the anwser say that bcrypt is optimally secure and has a flaw by design, the answer also say the algorithm is quite old (1999), the answer does'nt talk about Argon2 at all. The NIST document quoted is 2010. So I don't agree with you at all. Bcrypt not is but was the best password hashing algorithm. Now it's too old and blowfish not enough secure.

Argon2 was the winner of PHC in July 2015 but was already finished in March 2014. PHC winner mean that the algorithm was chosen and tested by all the best crypto expert of the world. Bcrypt is not only mature but also deprecated and crypto expert tell us to use Argon2 now. You also doesn't talk about scrypt, you can't say it's shiny new and not used, half of the crypto money use scrypt.

Argon2d implementation maximizes resistance to GPU cracking attacks, Argon2i is optimized to resist side-channel attacks, Argon2id is a hybrid version.

You need more crypto.stackexchange? Password hashing security of argon2 versus bcrypt/PBKDF2?

Here some saying bcrypt is the past, scrypt the present, and argon2 the future.

What people think on hacker news:

Quick answer: use Argon2i, unless you have very special needs.

Or another BCrypt vs PBKDF2 vs Argon2

[French] Si vous avez accès à une bonne implantation de Argon2, vous pouvez l'utiliser à la place de BCrypt.

[noraj]

@randomnonsense Not SHA512 but SHA512crypt (for password hashing). But as I already said SHA2 is a general use algorithm and was optimized for calculation so it is a lot easier to crack for attacker than algorithms specially created for password storage (Argon2, Bcrypt, ...) that was specially designed to be a nightmare to bruteforce. Here a detailed article explaining you why. Actually using SHA512crypt over Bcrypt is dropping the security.

When changing security you want to increase it not drop it. So the two candidate here are scrypt or argon2. Argon2 is the winner of PHC and has a node js wrapper: node-sodium or node-argon2. Note that libsoduim is a multi-algorithm lib, not only for argon2.

[jfurrow]

@noraj1337 I really appreciate your contributions to this issue; thank you for the thorough explanations and links to resources.

[randomnonsense]

Solution for FreeBSD is: Build node from ports, do not use packages. Bcrypt will compile fine. Solved.