Login Page Blank
-
Well, according to the documentation, that's NodeBB's default.
-
@Akito Well.... the devs had to pick something. And were likely on lappies sporting corei7's that did not notice it. As contrasted with a more minimally provisioned cloud vm? But thankfully cool enough to make it something you can tune to your needs rather than hard coded.
fwiw; Not something I have experienced but also not running on a minimally provisioned vm. Care to share details? Cuz if you have a lot of horsepower behind it them maybe I am out in left field here? Does setting it to lower (as contrasted with removing entirely as mentioned above) e.g. 7, help?
Not a cryptographer so unfamiliar off top of my head w/bcrypt default if left unspecified.
-
@Akito Holy, holy, guacamole! I guess I misread your initial post. Mea culpa!
I seem to recall bcrypt supports max rounds of 31. Since you got all that power to spare, maybe test with 31 that and see if it works, just as curiosity.
-
12 rounds was the default (or at least, it was in the implementation examples we used). bcrypt needs to work reasonably fast on a 1 core 512mb machine, otherwise we wouldn't be able to tell people NodeBB can be installed Basically Everywhere
-
@gotwf said in Login Page Blank:
I seem to recall bcrypt supports max rounds of 31. Since you got all that power to spare, maybe test with 31 that and see if it works, just as curiosity.
Max cost is 31, though it doesn't mean rounds. If n is the cost, the number of rounds is 2^n, so since I think no system is using 64-bit integers for BCrypt rounds (not to mention how big that amount would be! I'd expect timeouts if you actually tried to compute more than a quintilion iterations for cost factor of 63) the only two options after that are overflow and breaking (max value of 32-bit integer is 2^32-1). So if 36 worked, you'd get much less security than with 12 - because it'd overflow back to 4...
@Akito
So yeah - don't use anything over 31. If it works, you just used a low cost factor without knowing it. In fact, I'd recommend against 31 too, since I'd expect that some implementations might use signed integers instead and then you just tried to use negative amount of rounds. 30 is the maximum number that should work, but I think that's a bit excessive. Suit yourself though.I'm kinda wondering though - would it be possible to change the hashing algorithm with a plugin? Bcrypt is quite, well, old. And while it means it's well tested and doesn't have any fatal flaws, it also means it's well tested and attacking it is just much cheaper than newer algorithms. Especially with GPUs and even more with ASICs. It was just not designed with current hardware limitations in mind like scrypt and now the likes of Argon2, which was made to resist GPU attacks and side channel attacks (well, technically, only one of them at a time, though argon2id just uses both methods one after the other mitigating this issue - and it's usually the default and recommended method).
-
@oplik0 This would be cool but those algos are still relatively untested by time and not seem to be percolating into much use/support. Been waiting on that to change for a while now.
Meanwhile back at the farm, I trust bcrypt pretty well because I have high regard for OpenBSD, wh/has used blf-crypt to hash /etc/password since... ever since I can remember. Not kept up w/any of this though so I may well stand corrected.
-
scrypt is pretty well tested by now - after all, it's been around for 11 years now and it's similar to PBKDF2 in many ways (if I remember correctly scrypt is actually using a variant of PBKDF2 as a part of the algorithm, but is additionally memory-hard making it much harder for GPUs, since memory doesn't scale as cheaply as cores there).
Argon2 also isn't some "new flashy thing" by now. PHC was started in 2013 and Argon2 emerged as a winner in 2015 - even if we're only counting version 1.3 that was released in 2016 that's still 4 years of being possibly the most interesting target for security researchers (especially those salty that their favored scheme lost
) and it actually was fixed after an attack was published that decreased the complexity of cracking argon2i (didn't affect argon2d and I think argon2id was also safe due to its hybrid approach. The mitigation in 1.3 means that the attack only affect single pass argon2i, so even just using 2 passes it shouldn't apply - and you should be using multiple passes anyway).And argon2 is slowly seeing adoption - it's one of 3 main hashing algorithms supported by django (pbkdf2 and bcrypt being the other ones) and the only reason for pbkdf2 being the default is the fact that argon2-cffi library for python that's used there is written in c (as the name suggests) and requires compilation, meaning that it might not be compatible with every system - so it's better to ship with an algorithm that should work everywhere. Yandex even made their own implementation. Dashlane is using it by default (I think they also support pbkdf2 if you want :V). And I think libsodium defaults to argon2id. So I think the adoption will be rising - especially as services slowly move away from bcrypt and pbkdf2 - as argon2 is a great alternative to scrypt. For example I remember that Protonmail is considering argon2 as a replacement to bcrypt when they get to changing their authentication system (thought by then it will be well tested
).If you want something more... new and shiny but kinda unknown - I'd recommend looking into some of the other PHC finalists - Lyra2 is interesting and at least the main reason it didn't win was apparently that it's only hybrid (like argon2id - so no equivalent to argon2i or argon2d separately), Makawa allows for unique delegation feature (allowing to compute part of the hash on untrusted system - which could allow to make the computation much more expensive and offload it to for example shared servers or even clients), battcrypt and pufferfish apparently just went all-in on blowfish and are just bcrypt but more, and yescrypt is apparently backwards-compatible with scrypt (that is, it can also compute scrypt hashes, so you could just "upgrade" without requiring any actions from users or using two different functions for hash computation).
-
If we were to switch hashing algos, it'd probably be to Argon2 as preliminary reports seem positive. Definitely want to wait until it's battle-tested like bcrypt
Is it worth letting plugins change the hashing algo? Probably not, it's not something you want people to mess around with, and if we did open it up, someone'd probably write
nodebb-plugin-rot13and knowing how things work, hundreds of people might download and install it
So... let's not go there, shall we?
-
Now I just feel the need to create
nodebb-plugin-rot26. BRB, trying to mockbcryptjsto providegenSaltandhashfunctions that do nothing andcomparefunction that just compares two strings
