Login Page Blank



  • My login page is (almost) entirely blank on my production server but works ok on dev and staging (heroku). I can see the home page and I can create an account and see the profile page, but I cannot login to an existing account:

    0_1458756653665_Screen Shot 2016-03-21 at 12.41.34 PM.png

    There are no javascript errors in the browser and no errors in the server side log:

    21/3 14:33 [24540] - info: NodeBB v0.9.2 Copyright (C) 2013-2014 NodeBB Inc.
    21/3 14:33 [24540] - info: This program comes with ABSOLUTELY NO WARRANTY.
    21/3 14:33 [24540] - info: This is free software, and you are welcome to redistribute it under certain conditions.
    21/3 14:33 [24540] - info:
    21/3 14:33 [24540] - info: Time: Mon Mar 21 2016 14:33:07 GMT-0500 (PET)
    21/3 14:33 [24540] - info: Initializing NodeBB v0.9.2
    21/3 14:33 [24540] - info: Environment: production
    21/3 14:33 [24540] - verbose: * using mongo store at xx.xx.xx.xx:xxxx
    21/3 14:33 [24540] - verbose: * using themes stored in: /var/www/blahblahblah/live/node_modules
    21/3 14:33 [24540] - info: [database] Checking database indices.
    21/3 14:33 [24540] - verbose: Checking dependencies for outdated modules
    21/3 14:33 [24540] - verbose: [notifications.init] Registering jobs.
    21/3 14:33 [24540] - verbose: [meta/css] Minifying LESS/CSS
    21/3 14:33 [24540] - verbose: [sounds] Sounds OK
    21/3 14:33 [24540] - verbose: [meta/templates] Compiling templates
    21/3 14:33 [24540] - verbose: [meta/templates] Successfully compiled templates.
    21/3 14:33 [24540] - verbose: [meta/css] admin.css committed to disk.
    21/3 14:33 [24540] - verbose: [meta/css] stylesheet.css committed to disk.
    21/3 14:33 [24540] - verbose: [meta/js] Minification complete
    21/3 14:33 [24540] - verbose: [hotswap] Router with id plugins replaced successfully
    21/3 14:33 [24540] - verbose: [plugins] All plugins reloaded and rerouted
    21/3 14:33 [24540] - verbose: [hotswap] Router with id auth replaced successfully
    21/3 14:33 [24540] - verbose: [meta/js] Client-side minfile committed to disk.
    21/3 14:33 [24540] - info: NodeBB Ready
    21/3 14:33 [24540] - info: Enabling 'trust proxy'
    21/3 14:33 [24540] - info: NodeBB is now listening on: 0.0.0.0:4567



  • Just came across this as well on a very new installation (ubuntu 16.04).

    No console errors, no ./nodebb dev errors. Have only installed a handful of plugins which are all fine. No .tpl files have been edited.

    alt text



  • did someone knows how to fix this problem, im installing nodebb for my project and im having this issue and couldnt find any help anywhere

    please help



  • Same issue here. Totally stuck here.



  • @Akito said in Login Page Blank:

    Same issue here. Totally stuck here.

    This might help:

    https://community.nodebb.org/topic/14672/fresh-installation-seems-broken



  • @crazycells

    Greetings, thank you for the quick reply!

    I discovered, that increasing the bcrypt_rounds was slowing down the server so much, that it could not save the Admin password properly on first run. So it never had an Admin to refer to. Once I removed the env var for increasing the bcrypt_rounds (defaults to 12), everything went smoothly, as it should.

    Not sure if this is a bug with NodeBB not handling increased bcrypt_rounds, properly.


  • Community Rep

    @Akito Hmm.... Twelve seems a bit high as a default. Maybe somewhere around seven to nine would be more reasonable? Above that you really start to notice the extra rounds. For example, the IMAP server Dovecot's password bcrypt rounds is allowed to range from a minimum of something like 4 to a max of 31, and defaults to 5, iirc.



  • @gotwf

    Well, according to the documentation, that's NodeBB's default.


  • Community Rep

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



  • @gotwf

    The default 12 work fine, without problems. Only when I had it set to 36, the server had timeouts, as described above.

    As for the official VPS specs:
    4 vCores, 8GB DDR4.


  • Community Rep

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


  • GNU/Linux Admin

    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™


  • Plugin & Theme Dev Community Rep

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


  • Community Rep

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


  • Plugin & Theme Dev Community Rep

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


  • GNU/Linux Admin

    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-rot13 and knowing how things work, hundreds of people might download and install it 😆

    So... let's not go there, shall we?


  • Plugin & Theme Dev Community Rep

    Now I just feel the need to create nodebb-plugin-rot26. BRB, trying to mock bcryptjs to provide genSalt and hash functions that do nothing and compare function that just compares two strings


Log in to reply
 

Suggested Topics

  • 9
  • 6
  • 2
  • 12
  • 36
| |