When logging in to Admin getting unable to generate password hash

[alan]

This post is like these two but I've not been able to fix my problem reading those threads (perhaps partly because I don't fully understand some of the exchanges as they skip past things I am not familiar with).

With debug turned on, when I try to login I am getting (domain and password substituted out):

TEMPLATEFILE : UNABLE TO GENERATE PASSWORD HASH
#0 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/PASSWORD.PHP(33): PASSWORD->HASH('MY-PASSWORD')
#1 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/SESSION.PHP(310): PASSWORD->MATCHES('MY-PASSWORD')
#2 [INTERNAL FUNCTION]: SESSION->___AUTHENTICATE(OBJECT(USER), 'MY-PASSWORD')
#3 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#4 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('AUTHENTICATE', ARRAY)
#5 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/SESSION.PHP(262): WIRE->__CALL('AUTHENTICATE', ARRAY)
#6 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/SESSION.PHP(262): SESSION->AUTHENTICATE(OBJECT(USER), 'MY-PASSWORD')
#7 [INTERNAL FUNCTION]: SESSION->___LOGIN('ADMIN', 'MY-PASSWORD')
#8 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#9 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('LOGIN', ARRAY)
#10 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSLOGIN/PROCESSLOGIN.MODULE(77): WIRE->__CALL('LOGIN', ARRAY)
#11 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSLOGIN/PROCESSLOGIN.MODULE(77): SESSION->LOGIN('ADMIN', 'MY-PASSWORD')
#12 [INTERNAL FUNCTION]: PROCESSLOGIN->___EXECUTE()
#13 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#14 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('EXECUTE', ARRAY)
#15 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/PROCESSCONTROLLER.PHP(194): WIRE->__CALL('EXECUTE', ARRAY)
#16 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/PROCESSCONTROLLER.PHP(194): PROCESSLOGIN->EXECUTE()
#17 [INTERNAL FUNCTION]: PROCESSCONTROLLER->___EXECUTE()
#18 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#19 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('EXECUTE', ARRAY)
#20 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/ADMIN.PHP(45): WIRE->__CALL('EXECUTE', ARRAY)
#21 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/ADMIN.PHP(45): PROCESSCONTROLLER->EXECUTE()
#22 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/SITE/TEMPLATES-ADMIN/CONTROLLER.PHP(13): REQUIRE('/VAR/WWW/VHOSTS...')
#23 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/SITE/TEMPLATES/ADMIN.PHP(13): REQUIRE('/VAR/WWW/VHOSTS...')
#24 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/TEMPLATEFILE.PHP(125): REQUIRE('/VAR/WWW/VHOSTS...')
#25 [INTERNAL FUNCTION]: TEMPLATEFILE->___RENDER()
#26 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#27 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('RENDER', ARRAY)
#28 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PAGERENDER.MODULE(250): WIRE->__CALL('RENDER', ARRAY)
#29 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PAGERENDER.MODULE(250): TEMPLATEFILE->RENDER()
#30 [INTERNAL FUNCTION]: PAGERENDER->___RENDERPAGE(OBJECT(HOOKEVENT))
#31 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#32 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('RENDERPAGE', ARRAY)
#33 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(293): WIRE->__CALL('RENDERPAGE', ARRAY)
#34 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(293): PAGERENDER->RENDERPAGE(OBJECT(HOOKEVENT))
#35 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('RENDER', ARRAY)
#36 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSPAGEVIEW.MODULE(97): WIRE->__CALL('RENDER', ARRAY)
#37 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSPAGEVIEW.MODULE(97): PAGE->RENDER()
#38 [INTERNAL FUNCTION]: PROCESSPAGEVIEW->___EXECUTE()
#39 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY)
#40 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('EXECUTE', ARRAY)
#41 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/INDEX.PHP(192): WIRE->__CALL('EXECUTE', ARRAY)
#42 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/INDEX.PHP(192): PROCESSPAGEVIEW->EXECUTE()
#43 {MAIN}

So far I have:

1. replaced /wire/ with a fresh 2.3 copy
2. set /site/assets/cache/ plus all contents to 777
3. set /site/assets/sessions/ plus all contents to 777
4. installed a copy of PW 2.3 in a sub-domain and checked it can login OK (server environment check) and all OK

I am able to update the site by updating locally and then export/importing the database.

I would be grateful for any suggestions as to how I can solve this, thanks in advance for comments!

[Radek]

Hi, i had this problem and it is related with bugged blowfish in PHP older than 5.3.7.

So if you generate password on newer PHP than 5.3.7 and move to older PHP you have this problem.

Best suggestion is upgrade PHP. I temporary solved it this way.

[alan]

Thanks Radek very much for that.

I tried it and have made a little progress.

Now when I try to login rather than the error I get

ADMIN - LOGIN FAILED

or with debug turned on

PROCESSLOGIN : ADMIN - LOGIN FAILED

So I am still stuck, just with a cleaner error screen, but thanks once again for the suggestion.

[Radek]

Ok, so now you must generate new password for users because in your DB table field_pass (data,salt) is hashed with blowfish and blowfish is disabled with that little hack from my previous post. Its little tricky because you cant login to that system. I made new pass for admin user  on my localhost where i was logged. I changed Password.php to disable blowfish, in administration backend set new pass and alter DB table field_pass(data,salt) for admin user on broken server.

[alan]

Thanks  Radek, I will re-read these steps and check again—I thought I'd done this (I did a password change and export/imported the db etc) but I will re-check and try again; cheers!

[alan]

Hmm, this process did not directly work for me, I followed the steps but kept being denied access at the remote site.

I then managed to lock myself out of my local site!

So I used this Ryan tactic to get back into my local site, all good.

Then I decided to try it at the remote site, so I uploaded a template with the password reset code and visited the page to make it run, returned to the admin login and WAS able to login.

It now seems that if I change password locally and export the db to the remote site I kill the ability to login remotely but once I've fixed that with Ryan's tactic and am able to login at both ends I am now able to export the db locally and import it at the remote end (so able to move edits about if I need to) then login does not get broken and only re-breaks if I change the password locally.

I am going to setup a vanilla clean install of 2.3 locally and then try to see if get the same (inability to login at the remote end without hacking about) or if I am able to login AOK. I hope it will be the latter (if it is then all I need to do is understand what is special about this install that it has this fragility). Will update this thread when test complete.

Thanks again to Radek, Ryan et al.

[DaveP]

Forgive me if I misunderstand the problem, but are you aware of the $config->userAuthSalt setting in config.php?

/**
 * Installer: User Authentication Salt 
 * 
 * Must be retained if you migrate your site from one server to another
 * 
 */
$config->userAuthSalt = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx';

(Around lines 223-229 of config.php (near the bottom, anyway))

[alan]

No forgiveness needed if I was aware or not Dave; /always/ happy to have suggestions

Yes I am aware of it insomuch as I saw it mentioned in another thread but I did not know much about it other than I was indeed retaining the contents of config as all I was doing was installing locally, copying all files up to the remote, exporting/importing the db from local to remote; so I'm assuming this is not the cause(?)—but thanks for the suggestion all the same!

[DaveP]

The process as you describe it is exactly how I promote a site from local dev to live server, so that wouldn't be expected to be the problem. Can only think that it must|might be related to a difference in PHP version between the two environments and the problems discussed in the threads you link to above.

Just for 'fun' it would be interesting to try the process in reverse - try to recreate a working remote site locally using file copy and db export method. If the same or similar problems arise, then the two environments must be sufficiently different to cause a problem. (Not suggesting for a moment that you should, but it might be interesting...) 

[alan]

Thanks for the suggestion Dave, I may try this if I have time

OK: The result is as follows (my hosting is stuck at PHP 5.3.5):

## Test 1

1. with MAMP PHP ver 5.4.10 install PW 2.3 locally

1. copy files and db export to hosting

1. go to login at hosting results in `Unable to generate password hash`

## Test 2

1. with MAMP PHP ver 5.3.20 install PW 2.3 locally

1. copy files and db export to hosting

1. go to login at hosting results in `Unable to generate password hash` see update 2013-05-13-1310

Conclusion: If I am correct then (since PW 2.3?—I've never seen this before so I am wondering if this came with v 2.3 of PW) if your hosting env is below 5.3.7 and you export/import a db from a local copy of a site to the hosting env then logging in won't work and will require the password being reset with a combination of Ryan's tactic and the edited Password.php file noted by Radek. NOTE: This conclusion may well be incorrect but I've run out of 'clever' and need some confirmations from those much cleverer than I on PHP/security/PW.

Bottom line it's making me think I ought to upgrade my hosting past PHP 5.3.7; only trouble is it seems it's NOT easy to do this with an (mt) dv setup unless you are more of a sysadmin than I am :/ Crap.

UPDATE 2013-05-13-1310: if my local env is set to PHP 5.3.20 (so like my hosting which is at 5.3.5 they are both below 5.3.7) then as long as I reset the local password as explained in 'Conclusion' above then I can now export a local db and import it over at hosting and login OK.

Edited May 13, 2013 by alanfluff

[ryan]

It's correct that passwords can't be retained if you are developing a site in > 5.3.7 and migrating to a server running < 5.3.8. Best bet is to avoid any web server running an old version of PHP. But if you can't do that, then you'll want to reset your password at the live server after migrating the site to it. I usually paste this into my site/templates/admin.php, open the /processwire/ URL (to run it), and then remove it.

$u = $users->get('ryan');
$u->of(false);
$u->pass = 'mypass';
$u->save(); 

[alan]

Thanks Ryan for that beautifully succinct summary of what I was struggling to work out(!).

I have almost bitten the bullet that is upgrading my hosting (by migrating to an uprated product that has PHP 5.4.x) and until I do I will just continue to use that simple work-around.

Thanks for the clarification Ryan

[Godfrey]

Thanks for going through this trouble alan, this thread and the simple workaround helped me a bunch.  I was struggling for hours with the same problem

[thijs]

Hey all,

I’ve run into the same problem, moved a site to another server (php 5.3.2.) but with an extra hurdle, when I try to reset the password through the API, it throws me a 500 Internal Server Error, which is logged as:

Error:     Exception: Unable to generate password hash (in /var/www/vhosts/stage.vandejong.nl/httpdocs/depit/wire/core/Password.php line 270)

Edit: Radek’s fix  (adjusting Password.php) did the trick.