Thanks for the reply!
STO? Yeah, makes sense. Too many items don't line up, but I'm getting a picture of the security model- with a few parts that don't make sense.
I've been reading the posts about Moodle hashes, but when I see a previous dbpass of 10 alpha numerics and claiming to be MD5, it doesn't line up.
The hashes in the db I recognize as hashes, but the thing stored in config.php...
I changed the username and pwd in MySQL and no problem putting the dbuser and dbpass in config.php- as long as dbpass is cleartext (which I do not like)
Sure, I can move the file outside public_html, using an include of sorts as suggested by others (and I still may), but I also do not want to leave a cleartext pwd in ANY files.
It seems so simple:
1. I have the db password
2. Apply the requisite hash method
3. Insert hash into dbpass field
So I tried with MD5, both with and without the salt added to the end of the password and inserted into dbpass, but no joy. Comment back to use the cleartext pwd and it works again.
I had to rename the prefix of the database from servershortname_mdl1 to newservershortname_mdl1 and made the changes in config.php
I don't know if that has any effect on the pass, salt, or hash? I don't know that much about Moodle's internals yet ;)
I don't understand why config.php passes the cleartext pwd okay and has the salt still listed (not disabled)? Unless Moodle wants to control the db pass and matches up its own salt/hash at that time? Or there is some trigger to use a hash vs cleartext somewhere?
BTW, this username/pwd is not stored in the user db, it is setup in the SQL admin. If I'm sure the config.php dbuser will use a hash that is placed in the user table, I guess I could set up a dummy user with the same pwd, grab the hash from the db field and reverse it against the salt, but that's a bunch of effort ;)
I'm not really this dumb, but for whatever reason the dbpass and how it is used (and what I need to insert) isn't clicking.
So set me straight and we'll have a laugh on me