phpBB2 -> SMF1.1 converter issues discovered.

[0897jhPEFUOIyG90]

SMF Version: SMF 1.1 RC3
In phpbb2_to_smf.sql dated 8/7/2006 12:04 AM

The default values for labels in the pm_recipients table for imported PMs is blank instead of -1, totally borking the PM system.
(line 385)

There are several superfluous AS clauses within SUBSTRING functions in some of the queries that will cause the import to fail.
(lines 133,135,136,367)

If uploaded avatars are referenced in the source phpbb database but not present on disk the converter will note this in its output but then choke on the pastTime function for some reason, looping continually as it maxes out the cpu.

[Ferny]

And many others

See http://www.simplemachines.org/community/index.php?topic=107868.0

[stockkarts]

we also have a problem

http://www.simplemachines.org/community/index.php?topic=112262.msg727938#new

we would really like to convert

[0897jhPEFUOIyG90]

Also, user passwords are not converted properly, all imported users will be unable to login, this is major. Looking for a fix...

[Oldiesmann]

As I stated in another topic, SMF already detects MD5 encryption, so either the converter isn't copying over the passwords or phpBB uses more than straight MD5 encryption...

[Ferny]

Also, user passwords are not converted properly, all imported users will be unable to login, this is major. Looking for a fix...

I converted my forum and the users I tested had no problems to login...

[青山 素子]

phpBB uses plain un-salted MD5. If you are coming from a conversion from Nuke-Evolution (a fork of phpbb for PostNuke), the writers of the software make the password undergo 5 MD5 hashes.

[0897jhPEFUOIyG90]

As I stated in another topic, SMF already detects MD5 encryption, so either the converter isn't copying over the passwords or phpBB uses more than straight MD5 encryption...

The converter is copying over the passwords and they are straight MD5 hashes from phpBB.
phpBB uses straight MD5, however SMF 1.0.x does not:

Code Select Expand


function md5_hmac($data, $key)
{
$key = str_pad(strlen($key) <= 64 ? $key : pack('H*', md5($key)), 64, chr(0x00));
return md5(($key ^ str_repeat(chr(0x5c), 64)) . pack('H*', md5(($key ^ str_repeat(chr(0x36), 64)). $data)));
}


So code in SMF 1.1 that is intended to update an SMF 1.0.x password (salted, characters added, double MD5) with user input to an SMF 1.1 SHA1 password logically to me will not be able to detect and compare hashes of a plain MD5 hashed password from phpBB if it is assuming old MD5 passwords it finds are from SMF 1.0.x.

This code from SMF1.1 RC3's Login2 function:

Code Select Expand


// The hash should be 40 if it's SHA-1, so we're safe with more here too.
elseif (strlen($user_settings['passwd']) == 32)
{
// vBulletin 3 style hashing?  Let's welcome them with open arms \o/.
$other_passwords[] = md5(md5($_REQUEST['passwrd']) . $user_settings['passwordSalt']);
// Hmm.. p'raps it's Invision 2 style?
$other_passwords[] = md5(md5($user_settings['passwordSalt']) . md5($_REQUEST['passwrd']));
}


Does not appear to me to support detection of a straight unsalted once hashed MD5 password from phpBB.

So perhaps adding this to the above would allow for detection of phpBB passwords?

Code Select Expand


// phpBB 2 style hashing?
$other_passwords[] = md5($_REQUEST['passwrd']);


But it looks to me like SMF1.1 is SHA1 hashing the password with javascript before it is sent to the login script anyway (a good idea to stop sniffing of passwords) so none of these detections will work because $_REQUEST['passwrd'] is actually an SHA1 hash?  (using the $_REQUEST array instead of the $_POST array has its own security issues as well...)

Also, user passwords are not converted properly, all imported users will be unable to login, this is major. Looking for a fix...

I converted my forum and the users I tested had no problems to login...

Did you test users that did not exist in the destination SMF database before the import? Because I was under the same impression as you until users from the imported phpBB database that did not already exist in the destination SMF database were tested.

Its not the end of the world, just a pain, as all users must request a new password be mailed to them before they can login on the new SMF forum. (and must be notified of this by mass-mail or notices posted on the site)

However Ferny has gotten my hopes up that there is a solution that avoids this... 

[Ferny]

I made a fresh install of smf 1.1-RC3, no users appart from administrator on it. I imported phpbb 2.0.21 database, and tried a pair of users on smf (the administrator and a test user that I had on phpbb). It worked fine, I had no problems to login.

[青山 素子]

So code in SMF 1.1 that is intended to update an SMF 1.0.x password (salted, characters added, double MD5) with user input to an SMF 1.1 SHA1 password logically to me will not be able to detect and compare hashes of a plain MD5 hashed password from phpBB if it is assuming old MD5 passwords it finds are from SMF 1.0.x.

There is also code to detect an unsalted MD5 password. If the salt column is blank, the software tries several methods to authenticate.