(2011-09-26, 05:27 PM)Tom K. Wrote: [ -> ] (2011-09-26, 05:05 PM)PJGIH Wrote: [ -> ]A choice between MD5 and SHA would be cool, too. The option would be stored in the config.php file. The people wouldn't know what encryption you were using. Or, maybe
md5(sha1($salt.$password.$config['passkey']))
We've just been discussing that 
@labrocca: what potential problems are there? As long as all the relevant login functions are modified, it should be pretty easy to do. The only problem would be converting current passwords. Maybe something like:
md5(md5($password.$salt).$config['encryption_key']);
Then the upgrade script would simply update all records with:
//get all users and store in $results
for each $passwordhash in $results {
$newpass = md5($passwordhash.$config['encryption_key']);
//insert new updated password
}
Maybe I'm not thinking straight but I don't think it will work because of the salt. The password hash is already salted in the DB and if you add a key then the password will no longer work. I'd have to test to verify but I think a change of salt-pass-key would create a completely new hash from the actual password. Not just from it's hash. The merge system does this by adding a column and a plugin so that a login is checked for an old version password and then updated to the new algo if it matches.
If it's possible to do the key with your method then I'd love to see it in the 1.6x branch. An update to add a random key then redo all passwords would be rock and roll.
It should be fine
Now the passwords are md5($password.$salt) are they not?
All I propose to do is rehash that with another level of md5() to:
$currentpass = md5($password.$salt);
$newpass = md5($currentpass.$config['key']);
So then the login function would simply need to be altered to:
md5(md5($password.$salt).$config['key']);
I'll have a look tonight at a test MyBB install, and see if I can get it to work
@Tom K absolutely let us know if that works. If so maybe we can get dev team to add this.
This is the current setup:
MD5
(
MD5
(
PLAINTEXT PASSWORD
)
+
SALT
)
Theoretically we could have another string appended to the (current) final MD5 hash and then MD5 it again without any problems. But for databases with a lot of users this would be a dramatic change in an upgrade script.
Some sort of recursive script would be fine, doing x amount of users at a time. You would simply need to check if the current versions is less than 1.6.5, if so upgrade to the new setup
Ok, i am trying to test this but I can't remember which file the login function is contained within Help pl0x 
nvm
its in functions_user.php
See here for the new discussion:
http://community.mybb.com/thread-104768.html
We can get this thread back on topic now
(2011-09-26, 05:05 PM)PJGIH Wrote: [ -> ]A choice between MD5 and SHA would be cool, too. The option would be stored in the config.php file. The people wouldn't know what encryption you were using. Or, maybe
md5(sha1($salt.$password.$config['passkey']))
You realize that doing an md5 of a sha1 is decreasing security, right?
(2011-09-28, 07:38 AM)Pirata Nervo Wrote: [ -> ]I haven't read that thread yet but there's no way to guess if it's been "upgraded" already or not unless a new field is added to the table in which we store 1 or 0. I'll read that thread in about 20 minutes
Actually, you'll know for a fact what version the forum is upgrading from. You'll know for a fact that any version before 1.6.x (where x is the constant revision number when the system is implemented) is not using the upgraded system, and you'll know for a fact that any version including and after 1.6.x uses the upgraded system.
Pseudocode:
if(currentVersion < "1.6.x")
upgradePasswords()
else
leavePasswordsAlone()
Since the proposed system is simply an extra layer on top of the current one, rather than making a significant change to the current one, you can upgrade all of the passwords at upgrade time.
imho if someone can make a decent successful working plugin it might be more convincing that this will work in production.
(2011-09-28, 04:49 PM)Firestryke31 Wrote: [ -> ] (2011-09-28, 07:38 AM)Pirata Nervo Wrote: [ -> ]I haven't read that thread yet but there's no way to guess if it's been "upgraded" already or not unless a new field is added to the table in which we store 1 or 0. I'll read that thread in about 20 minutes
Actually, you'll know for a fact what version the forum is upgrading from. You'll know for a fact that any version before 1.6.x (where x is the constant revision number when the system is implemented) is not using the upgraded system, and you'll know for a fact that any version including and after 1.6.x uses the upgraded system.
Pseudocode:
if(currentVersion < "1.6.x")
upgradePasswords()
else
leavePasswordsAlone()
Since the proposed system is simply an extra layer on top of the current one, rather than making a significant change to the current one, you can upgrade all of the passwords at upgrade time.
You can know the version but you can't know which users have been updated, that's what I meant. Unless you pretend to add a new field like I said.