Not a bug PHP7 crypt() Error with salt format

I snipped out the image as it showed some sensitive details. It actually showed the user's password in the backtrace, so it'd be a good idea to change that password (after some potential debugging).

Looking at the backtrace, it appears to be generating a different format than I'd expect. It looks like the server doesn't (or didn't) have Blowfish support so it fell back to DES. However, looking at what got passed in isn't something that I think the code should have actually generated. I think I may need to see the raw original hash for this user (before the password gets changed). Is that viable? It'd be in the xf_user_authenticate table for this user_id. (Clearly don't provide it here; it can be sent to me privately.)
 
Hi Mike, thanks for your comment.

This forum was imported by me from an old custom application a year ago. I had written a custom importer to import the users. So it is possible it may be a mistake on my end. But this has only happened for a handful of users (less than 10) from several nearly three thousand who have reset their passwords, so it's strange.

There is a data column and a remember key in the xf_user_authenticate table. I am not sure which one you want so I have taken a sql insert export and sent you the row in a PC for the latest user this has happened for.
 
Based on some details, this does appear to be related to the data that was custom imported and not something that could be generated by XenForo itself. The error can generally be disregarded as deprecation errors (which is what's triggered) are just logged; they don't block execution unless in debug mode.
 
Top Bottom