Login, Registration, Encryption and more!

[Bartman]

Okay ... here's the scoop.

I converted my YaBB SP1 forum to YaBB SE 1.3 with no big conversion problems. Also applied the Bug Fixes to SE 1.3.

In order for my old members to be able to login to the new SE version, I changed the password seed to ya (the default was ys I believe).

The problems I'm having is that new members who have Registered since the SE conversion can not login successfully. I have tried this myself and constantly get an Error Message which says that the password is incorrect.

YaBB is emailing my new members temporary passwords, but they don't work. I've even changed the settings so that no password is emailed; still doesn't work. Also, if an existing member changes his/her password ... they are no longer able to login successfully. If I manually change a member's password from within their profile, they can no longer login successfully.

I've read through every post and thread I can find here and have found nothing that will solve the issue. I've corrected the form close tag in Register.php and have perused every Source file to see what I can find .... which is nothing.

Here's what I think the problem is:

The new encrypted passwords are not using the $pwseed that I established. If I go to PHPMYADMIN I notice that none of the new registrants have the ya seed included in their passwords. Whether it's the temp or changed password.

I've checked the LogInOut.php, Register.php, etc., and don't really see where YaBB is even using the password seed in the scripting.

Any suggestions?

_{I'm desperate}

[Joseph Fung]

the only time that seed is used, is when the password is encrypted in the cookie. THat's it.

The encrypted password you see in the database is encrypted using the 1st 2 letters of the passwd as the seed.

[mediman]

we make use of seed as salt!

$password = crypt($passwrd,$pwseed);

the seed you can only show in the "database stored password" if your server make use of standard DES, md5 i.e. starts ever with $1$, blowfish encryptet pw´s with $2$! only standard DES starts with the 2 sign salt!

medi

[Bartman]

the only time that seed is used, is when the password is encrypted in the cookie. THat's it.

The encrypted password you see in the database is encrypted using the 1st 2 letters of the passwd as the seed.

Okay ... great.

So why are all new registrations not getting the passwd seed?

The temporary password sent out to new members does not have the seed in it when you view the database. I know that it doesn't show up in the visual password (obviously). If I change someone's password by going to their profile ... the new password does not use the passwd seed when I look in the database. That's why they can no longer login.

So what is causing the program to not use the seed in the NEW cookies? Any thoughts on that?

Thanks!

[mediman]

what kind of encryption have you? Standard DES, Extented DES, MD5, Blowfish?

[Bartman]

what kind of encryption have you? Standard DES, Extented DES, MD5, Blowfish?

I don't have a clue how to find out; sorry.

$password = crypt($passwrd,$pwseed); does not appear in SE like this ... at least that I've seen. This is what SP1 uses ... but the scripting doesn't use this formula as you've written.

I really appreciate your response. If you could take me to the next level of understanding by explaining how I can find out what's going on, I would GREATLY appreciate it.

I can tell you that all of the NEW passwords (as they appear in my database) all begin with a 1 rather than ya, which is the seed. If I change a member's password in their profile, the new password begins with the first two letters/numbers of the new password. It's definitely encrypting, but I don't understand why it's not using the assigned seed.

Are you saying that my server can affect this?  

[mediman]

if you use the email password function then we use

Code Select Expand

$password = crypt(mt_rand(-100000,100000));
and with

Code Select Expand

$password = preg_replace("/\W/","",$password);
we delete all what is not number or letter!

then we limit it to a 10 letter password

Code Select Expand

$member['passwrd1']= substr($password,0,10);
and this password will be anotherone crytet!

with

Code Select Expand

$queryPasswdPart = crypt($member['passwrd1'],substr($member['passwrd1'],0,2));
how you can see we use (joseph said it before) the 1st 2 letters of the first encryption as SALT for the second encryption!

in the email now you can find $member['passwrd1'] as password but in the db is $queryPasswdPart stored!

the seed "ya" will here not used!

medi

btw: in Login2() we use

Code Select Expand

$password = crypt($passwrd,$pwseed); but this is for the cookie!

pwseed is defind in Subs.php

Code Select Expand

$pwseed = 'ys'; and in Load we use

Code Select Expand

$spass = crypt($settings[0],$pwseed);
to compare the crypted version of the password in the database with the password stored in the cookie.

but this has nothing to do with your issue!

[Bartman]

but this has nothing to do with your issue!

Okay ... I noticed all of that while doing my own investigation.

So if it has nothing to do with my issue ....... then what is my issue? Sorry to be so blunt, but I just need to cut to the chase here if you know what I need to be looking for as far as the real issue or problem.

Why is SE not recognizing the emailed password or any changed passwords? Everyone who was a member BEFORE the conversion can login in just fine. If someone starts fresh, no cookie on their computer, they register and await the emailed password, it doesn't work when they try to login in. Likewise if they change an existing password; they used to be able to login, but now they can't because the password that they changed to is not recognized.

Seems like SE is encrypting their passwords, but not decrypting it when they try to login, thus not recognizing the password.

Personally, I don't see how this is a server issue, but if you think it is, please let me know. I'm currentlly at a total loss as to what I should do.

[Joseph Fung]

Bartman - I just registered on your site (as Joseph) could you please send me an instant message with what my password looks like in the database?

[Bartman]

Thanks for looking into this Joseph. I just sent you an IM with your password as it appears in the database via PHPMYADMIN.

[Bartman]

Okay, here's a little update.

If I go and change my password in my profile, I get locked out of the forum. I then go and have a look at my database via PHPMYADMIN. There I can what the encrypted password looks like ... the one that doesn't work.

While in PHPMYADMIN, I can EDIT my membership file, change my password using the encryption results from my old forum which uses the password seed of ya ... and I'm back in business!

I've done this with several usernames which get locked out. To me this means my YaBB SE 1.3 is NOT using the seed I set up ... which you all explained ... and yet when I give it a password encryption series, via PHPMYADMIN, that uses my old seed ... the encryption begins with ya ... it works!

This seems to punch holes in what you all are saying.

While will YaBB SE recognize the encryption if it's not using the seed? I can type in my password, it decrypts it and I login. If I change my password through YaBB SE ... it doesn't use my ya seed, which you explained ... but it won't let me login in with it? It says the password is bogus ... even the temp ones that it emails to members don't work .... but ya seed versions do work.

To me this means the YaBB SE is expecting to decrypt passwords that use the ya seed .... or ys which is the default ... but I changed that to work with my conversion from YaBB SP1.

[Bartman]

More fuel for the fire!

I register a new user, SE emails me a password, I try the password ... it doesn't work; no surprise thus far for my board.

Now, if I go into PHPMYADMIN and replace the encrypted password that SE generated with the encrypted password which uses my ya seed ... I'm able to login.

So you see, there IS something wrong here, very wrong. The program is wanting to read and decrypt passwords ... thinking that they have ALL been using the password seed of ya. I guess I need to find a way to have SE generate passwords that use my seed. It's using it to decrypt ... and obviously it doesn't have anything to do with which seed I choose.

This is so freakin' bizarre.