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