Hi Beth,

What password format are you using?

Is this your dev environment using source code from the repository? The very latest code should be version 2.3.8.3, it doesn't sound like your working copy is updated to the latest code which is needed for the cache dependency files. I would first get your code up to the latest version by right clicking the top level folder and choose TortoiseHG > Update (default branch), then rebuild the solution and visit the setup page, it should have version 2.3.8.3.

Though nothing changed in terms of login since version 2.3.8.1 which is the version where we updated to stronger hashing and encryption with salt.

You can't really manually update your password in the db unless using plain text, since it would be stored as hashed or encrypted otherwise and you have no way of manually doing that.

There is a safety net setting you can put in user.config that will make it try all password formats if login fails:

<add key="CheckAllPasswordFormatsOnAuthFailure" value="true" />

and that would allow you to manually update it in the db to plain text (even when using encrypted or hashed) to get back in but you should not have to do that, so I would save that as a last resort and it won't really be a solution for lots of users if they are all failing.

With hashed or clear text the machine key does not matter but with encrypted it must never change, if the machine key is changed after passwords are encrypted then all users would be locked out and no way to recover the password. machine key on your dev environment needs to be that same as on production if using encrypted.

On your dev machine you could step through the code, setting a breakpoint in Web/Components/mojoMembershipProvider.cs in the ValidateUser method and in PasswordIsValid method and find out what is happening

Hope that helps,

Joe

Hi Beth,

There has not been a release of 2.3.8.3. A release is when I compile a build and make anew package of pre-compiled files for people to download. The source code repository is always the latest code, the version number corresponds only to changes int the database schema, ie new upgrade scripts are added with incremented versions every time I need to make any changes in the database. So currently in the repository the database is up to script 2.3.8.3 but other changes will be made before the next official release is packaged, amd possibly I will even need to make additioanl changes in the database and increment the upgrade script again before the next official release. But if you are using the latest code you should see the version as 2.3.8.3 since that is the most recent upgrade script in the repository.

Of course there will be errors expected if you run the latest code without running the upgrade scripts. New fields like "RolesChanged" get added by upgrade scripts and the newest code expects the new field, so the code and the database have to be in sync and that is what the setup page does it runs the scripts to upgrade the database to get it in sync with the latest code.

I'm not really sure what is going on, hashed password don't depend on the machine key so that isn't a factor.

My password is correct but the hash doesn't exist in the db at all.

What do you mean by that? Your password is correct where? in the database?

If using hashed passwords you will not see the password in the database you will only see the hash. The password field in the database is pwd not Password in case that is throwing you off. The Password field is a legacy field (no longer used) it was too small for the stronger hashing and stronger encryption so we migrated quite a while back from the Password field to a larger field Pwd. That change of fields was many versions ago, but we finally took advantage of the larger field in 2.3.8.1 when we implemented the stronger hashing.

The way it works with hashed password is the password you enter on the login page is concatenated with the value from the Password salt field then hashed and then the hash is compared to the hash in the pwd field, if it matches the password is correct.

We changed from MD5 hash with no salt to SHA512 hash with salt. Salt is just a random string concatenated with the password before hashing, it is stored in the PasswordSalt field. Its purpose is so that people who happen to use the same password don't have the same hash.

So when you try to login it is first trying to use the sha512 hash but if that fails it falls back to trying the old md5 hash (with no salt) so that it won't break any logins during upgrade. So I don't see how the change to stronger hashing could posisbly cause a login failure. Something else is going on here but I'm not really sure without being able to debug it myself.

If you want to email me a database backup and tell me a user name and password that should work I could try to debug it for you tomorrow, but I understand if you don't want to do that for data security reasons.

Best,

Joe