UBB.threads PHP Forum Software Community Forums Resources and Customizing How Do I? Old Password Encryption System?

Hi--I'm working to integrate my UBB board with Drupal (which we're switching to for the HTML portion of our site). It's slow going, but I'm making progress.

One problem I've run into is that many of our UBB passwords are apparently in some older form of encryption (pre md5) and I can't seem to find out what it is(was). Many of our user accounts date from 2001, so it'd be whatever system was in use then.

Thanks for any info and especially for any PHP function that would replicate that older encryption so I can have my drupal module check both for md5 encryption and for the older kind.

Regards--David Cardinal

I guess it depends on what version you are talking about.
Classic used a flat file system and did not encrypt anything.
According to the change logs Threads 6.x at first used php crypt before going to MD5. I never used the 6.x threads series.
But I would think they should have been converted to md5 if you have a newer version since then. Maybe the users you have problems with have not visited your site since 2001. So their passwords have never been rebuilt.

Classic didn't encrypt anything; however, during import to threads7 all passwords would have been MD5ed...

The only way to be able to figure out what is there would be to see what one of the passwords hashes looks like...

Of course we don't know what version you started with or ended up with.
Or at least what version the users in question registered with.
If you search for crypt here and look at some of the oldest posts you will see some notes on the issue.

Well, it's pretty easy to compare hashes if you see them...

The word "the":
MD5: 8fc42c6ddf9966db3b09e84365034357
Crypt: $1$AkpaJIz2$KmgjoOsdUqSA9dQf.SAeA/
Base64: dGhl

Hence why I said it'd be best if we could see one of the passwords ...

Thanks for all the answers. FWIW, the coded passwords didn't get changed in the udpate to v7 as (for example) mine wasn't _until_ I modified it at which point it became md5 encoded.

Some examples of the older encoding are (they seem to be a fixed length and shorter than md5):

.$dx1IaFEGidM
.$xnkZKKan5m2
.$dmQgpQk5Xsk

Thanks!--David

Looks more similar to crypt than anything else; but you're right, it is far smaller...

I didn't use threads in v6 to have the ability to have a comfortability with knowing the product; best bet is waiting to see if Rick to chime in...

Somewhere I read about when the change happened that crypt was updated to md5 when a user logged in again.
So again until Rick speaks up.
I would think the problem accounts are people that have not visited in a long long time.

I'd agree; it'd make sense to have them change their password here as the script wouldn't be able to automatically update one encoding algorithm to another when neither can be decoded...

Check out /libs/html.inc.php for the password authentication.

Basicly either the MD5 has to match, or the temporary password must match, and if so, it's converted to an MD5 password.

Look around this line on how ubb checks things:

Yarp,
I just noticed, You are a beta tester but not listed as a moderator. Why?

Yeh, looks to be crypt in that line

It was a salted crypt as I recall. And the problem we ran into was that it wasn't consistent form platform to platform. Moving a board from one OS to another pretty much guaranteed your password wasn't going to work. MD5 doesn't have that issue.

I was pretty sure that someone that logs in with a crypt password was automatically converted on login to MD5. Might want to double check that to be sure, but I'm fairly certain this is true still. If that is indeed the case you can be pretty sure someone with a crypt password hasn't visited in a long while.

I still wonder why we don't salt our MD5 ...

I wonder why we still use MD5.

Sha1 baby! lol...

Have you ever seen those MD5 databases? scary stuff...

Ruben, Gizmo & Yarp -- Thanks for the thoughts but they don't match what I'm seeing here. My personal account, for example, that I have used every day since at least 2002 (it turns out the first version of UBBThreads I installed for this board was 5.5.1 in April 2002) still has one of the shorter, older encoded versions of the password (until I changed it today & got an MD5 hash).

So from what I can tell:

1) The old crypt/hash/encoding is not automatically updated to a new system even if you use it every day and

2) It does not have to be either MD5 or a temporary password as the current version of UBBThreads still seems to be able to validate it.

So either there is some compatibility code with an older system or I'm missing something in how my board has been operating, or older boards have some legacy code hanging around that lets them do this even after upgrading.

Some type of salted crypt sounds pretty likely to me, but of course I'd need to know the specifics to validate individual encoded passwords.

Either way I have 4000 users and many of them are both active & have had accounts for a long time that I'd like to be able to preserve & validate going forward.

Hopefully Rick will have some info on how the passwords were encoded in UBBThreads 5.5.1.--David

From what I understand is that if no salt is defined the first two characters of the entered password become the salt.

FWIW, from looking at the suggested code (html.inc.php) it looks like not only does the do_login function check md5 but it also checks a simple crypt(), salted with itself (I presume for legacy support).

It does _not_ seem to update crypted passwords (which is consistent with what I've seen from doing testing).

In any case I think that gives me what I need, which is to check both md5 AND crypt when I compare passwords.

Thanks for the pointer to the code!--David