So I've been wondering about proper steps to convert md5 function to sha1. I think the following should be all steps, unless I miss something? : )

1. In database, in the _users table, change the following fields: 'user_password' | 'user_newpwdkey' | 'user_newpasswd' from 32 to 40 characters (sha1 takes 40).

2. In bb_cookie.php file, change the current writeUserPwd to this:

3. Look up and change this condition in files: admin_fileXXX.php, bb_cookie.php, and bb_func_login.php

from:

to:

4. Force password change via this code added to bb_plugins.php (keep this code for some time, a month or so):

5. Change admin password in setup_options.php to something strong.

Is it good, did it cover all scenarios? :

At first, I suppose you know that following PHP guide,

SHA1 stands not far away from MD5 in this case :)

Anyway, the proper solution below (I've tested on my local environment):

1. Change the length of the user_password field in the $Tu table (minibbtable_users by default) - here you are right:

2. bb_cookie.php - change default function to this (for an existing forum):

For a new forum, it's enough just to have:

3. On an existing forum, force your users to change/update passwords if they are still in MD5 (don't apply this for a new forum) - we could not change MD5 to SH1 straight, so it's really required that all of your users change or update the passwords manually:

4. OPTIONAL - if you are on a secured hosting and do not mind to keep the Admin's password in a clear form, change nothing. If you'd like to keep the Admin's password encoded in SHA1, do as mentioned in p.#3 of tom322's post above.

These steps could be useful also if you change to another encoding algorithm - except it would be much more difficult to plug it into existing forum, if the final encoding result is not equal to some defined length. For a new forum, another algorithm is more easier to plug-in at the initial forum running stage.

P.S. Always avoid any JavaScript "solutions", as more as possible :)

Thank you - from my tests it worked. BUT I was wondering about adding some random value to user-specified password so that in DB is never stored exact user password.

Currently there is this function:

What if we replaced it to something like:

Then the password stored in DB / cookie would never be the same as user entered it; in case of DB breach or a stolen cookie, attacker would only get this one-time password that is valid for forum and not valid for other things associated with this user's email (some people use the same password for different sites).

.. and if my suggestion above makes sense, what would be the best way of checking if current member changed password (I mean without changing md5 to sha1, so without comparing the lenght of the string) - I guess the only way would be to set a cookie in the action like:

?

DB actually doesn't store an exact password. Hashed value is compared to the same way encoded value user enters in the login form. DB stores an encoded version of it. There is a way to encode MD5 only if it's kind of a regular simple value, which is already available in a kind of known values database. If it's a difficult-to-guess password, it would take time to decode if it ever possible.

Your solution with replacing is not truly acceptable, I guess. MD5 is exactly about generating a unique hash for a value, but if you replace or change something, I doubt you could achieve that it will be unique, and some different values may have the same encoding value in result. It would make it even less secure. It's better not to touch a default function that way, and actually you won't achieve anything more secure with it.

I wouldn't rely on cookies in terms of some strong checking as well. What if this cookie is not set or deleted - you lose any chance to check for something.

Yes, even though my point was that since MD5 hash can be reversed into a real password, then adding these replacements would make sure that DB / cookie only stores a truly random password.

In other words, for security it would be best NOT to allow users to enter their own password but generate a random password for them, so I thought that adding this replacement function to the writeUserPwd function would achieve that because user-entered password would be randomized.

Besides, the replacements could actually add truly unique characters that users are unlikely to use but would make them stronger, like !@@#$%^&*()_+ etc.. I think it's a good idea:

It's a good idea to suggest users strong passwords, which they enter in forms, but it's absolutely not about changing an encoded value somehow. You won't achieve anything when making an intrusion into default encoding algorithm.

MD5 is the best around, right?
Today I was sitting in on a CS Capstone presentation (Final presentation before graduating, etc). One of my peers' presentation was today and I thought I'd check it out.

The person mentions that they salted and encrypted the stored user credentials within the database. At the end of the presentation, someone asked:

You mentioned that you store your user credentials by encrypting and salting them, so which algorithm did you use and how did you randomize the salt on each?

Their response:

I ended up researching algorithms a lot and decided to use MD5 because it's the most secure algorithm I've found. It also has a salt built in so I didn't have to worry about that.

If this is a quote, I'd be curious to know its author's credentials :)