Passwords 25 characters after upgrade to 6.3.0

[kran]

After upgrading passwords became 25 characters when I Reset & Send Password on the profile.

 

0pee8E0tP2+OVXaFWYeC2Q==

 

changing General Settings ---> Security ---> Required Password Strength has no "effect"

 

Thank you

[WHMCS Nate]

Hello Kran,

 

In WHMCS we changed the hashing algorithm we use to store client passwords to bcrypt. On a users first login to an upgraded system we rehash the password. We also rehash when you reset and send the password. You can see this in our release notes:

 

http://docs.whmcs.com/Version_6.3.0_Release_Notes#Version_6.3.0_RC_1

 

We think bcrypt is a great hash to use moving forward. We have designed the code to allow us to quickly add support for newer hashing algorithm when its widely available.

 

Since this is not really a bug report, I am going to move this thread to the technical discussion area.

 

Have a great day,

 

Nate C

[paperweight]

Hi Nate:

Ok, I've been having major issues with passwords and bcrypt since we updated to v6.x a few months ago. I have a long support thread too about this too, but there still seems no solution.

 

When our old users from prev.6x login, they are unable to do so. Only new users from 6.x are able to login. Plus, when any user tries to reset their password, the errors display too and the user is "locked out" form the clientarea.

 

Errors like this appear:

 

Fatal error: Uncaught exception 'RuntimeException' with message 'Calculated algorithm "unknown" is not supported' in /home/server/public_html/includes/classes/WHMCS/Security/Hash/Password.php:0 Stack trace: #0 /home/server/public_html/includes/classes/WHMCS/Authentication/Client.php(0): WHMCS\Security\Hash\Password->verify('testtest123@email...', 'U8Ny3clTAA3P0cD...') #1 /home/server/public_html/dologin.php(0): WHMCS\Authentication\Client->verifyFirstFactor() #2 {main} Next exception 'RuntimeException' with message 'Calculated algorithm "unknown" is not supported' in /home/server/public_html/includes/classes/WHMCS/Terminus.php:0 Stack trace: #0 [internal function]: WHMCS\Terminus->whmcsExceptionHandler(Object(RuntimeException)) #1 {main} thrown in /home/server/public_html/includes/classes/WHMCS/Terminus.php on line 0

 

Our server is running PHP version 5.6.21. ANy ideas what is happening?

[WHMCS John]

Hi,

 

Could you please ensure there are no customisations present on your installation as these can often change the way WHMCS operates.

These are typically located in the /includes/hooks and /modules/directories.

 

Once the issue is resolved you can add them back one-by-one until the problem begins again - at which point you have identified the troublesome customisation and can contact the vendor directly for assistance resolving the problem in their code.

[paperweight]

Hi, thanks for your feedback. Your support staff got back to me last night and it appears to be a modification on a module we have been using for a few years on WHMCS.

 

Questions:

 

1) Is there a method by which I can return on a page all the hooks being loaded? I want to pinpoint the actual hook creating the problem, so getting a list of hooks will help me go faster through the files.

 

2) is there a way to NOT use bcrypt? We use WHMCS to communicate with a radius server, an iOS app server, and some other connected services that share user info for authentication. Everything was running great until bcrypt was introduced, so I want to know if there is a way to revert to not using bcrypt with WHMCS.

 

Thanks for your help~

[brian!]

1) Is there a method by which I can return on a page all the hooks being loaded? I want to pinpoint the actual hook creating the problem, so getting a list of hooks will help me go faster through the files.

you could enable "Hooks Debug Mode" from settings -> general settings -> other

 

http://docs.whmcs.com/Other_Tab#Hooks_Debug_Mode

 

In order to troubleshoot problems with action hooks it may be necessary to log action hook activity, ticking this option will do so to Utilities > Logs > Activity Log.

NOTE: Enabling this option will result in a large number of activity log entries, so should be used sparingly and only when debugging hook problems. It should then be promptly switched off.

[paperweight]

Thanks for your help. For one action, it generated over 100 rows of hook calls, so is there a way to sift through each line to more accurately assess which hook is creating the problem?

[brian!]

John's suggestion is the usual method - e.g disable the hooks/modules and then enable them one-by-one to see where the problem lies.

it's possible some of the hooks are encrypted, so they'd be no way to check their code - that's why disabling is the easiest way... then once you've identified the culprit(s), you can then contact the author (whether that be WHMCS, third-party etc) and get a fix.

[paperweight]

Got it, thank you. We narrowed down the problem and were able to fix it a few days ago with just a few lines of code.

Edited September 14, 2016 by paperweight
spelling