Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Passwords not working after move

Go to End

8 Posts   3342 Views


Community Member, 59 Posts

29 July 2009 at 1:17pm

Hi All,

I moved a small SilverStripe site today and the passwords stopped working, and I just can't work out what's happened. I've looked in both databases(via PhpMyAdmin) and the table structure of the Member table is identical and the data is identical, yet the password won't work. I can reset the password to get it working, but I have another 2 sites to relocate over the next few weeks, one has lots of members that I don't want to have to get them all to regenerate their passwords. Does anybody know why this would happen???


Community Member, 231 Posts

29 July 2009 at 2:22pm

I've noticed this before - sometimes the differences in php versions mean that the hashes are generated differently. Not entirely sure what can be done about this - it might have something to do with the salt used?


Community Member, 59 Posts

29 July 2009 at 3:14pm

hmmm okay, the old version is 5.2.10 on debian/etch, the new version 5.2.9 on debian/lenny so they are different. I use dotdeb which rolled back to 5.2.9 due to problems with 5.2.10 so I can't get this new server up to 5.2.10. I did try loading the database onto my development machine which is 5.2.9 on etch, so it appears it may be the operating system version rather than the php version.

I've just stepped through the hashing code in the security class, everything is equal until it gets to:

$password = substr(base_convert($password, 16, 36), 0, 64);

that line gives different results, I have the feeling it's just a configuration setting, I'll experiment some more to try and isolate the issue better


Community Member, 59 Posts

30 July 2009 at 9:21am

I've found more on this:

a small piece of test code:

$str = str_repeat('1', 40);
echo $str . '<br />';
$str = base_convert($str, 16, 36);
echo $str . "<br />";
$str = base_convert($str, 36, 16);
echo $str . '<br />';

on all but Debian Lenny you get:


and on Debian Lenny(64 bit) you get:


I'm trying to find a configuration setting to fix it. To fix in SilverStripe, you'd need to modify the password checks to only use the first 10 characters of the packed hash.


Forum Moderator, 5523 Posts

30 July 2009 at 10:07am

See the discussion on this issue here -


Community Member, 59 Posts

30 July 2009 at 1:55pm

thanks for that - doesn't look like it's fixed yet, but may give me some ideas on how to patch it until 2.4 is released


Community Member, 59 Posts

30 July 2009 at 9:00pm

Edited: 30/07/2009 9:09pm

Would this be an acceptable hack?

	 * Check if the passed password matches the stored one
	 * @param string $password The clear text password to check
	 * @return bool Returns TRUE if the passed password is valid, otherwise FALSE.
	public function checkPassword($password) {
		// Only confirm that the password matches if the user isn't locked out
		if(!$this->isLockedOut()) {
			$encryption_details = Security::encrypt_password($password, $this->Salt, $this->PasswordEncryption);
			if ($this->PasswordEncryption == 'none')
				return ($this->Password === $encryption_details['password']);
			return (substr($this->Password, 0, 9) === substr($encryption_details['password'], 0, 9));

It looks to me like it would work for all cases, and it tests okay


Community Member, 2 Posts

5 October 2010 at 7:51pm

where would one implement this hack...?

we have just found today that all the passwords for users and admin folk on most of the sites that we have done in silverstripe have stopped working...

we suspect it is on sites that are pre ss2.4...

we can reset no worries with the forgot password thing but a couple of the sites have a biggish number of useres etc...