I managed to solve my problem by using guentherschmit'a suggestion in another post.

guentherschmidt wrote:

You can manually change the password in aspnet_Membership.  You'd need to change PasswordFormat to 0 and then enter a clear text password.  You'll also need to change passwordFormat to "Clear" in web.config.

What got me with mine was that it was a clean install.

Ken

gsc4 wrote:

The MachineValidationKey(s) and MachineDecryptionKey(s) in the web.config files included with the 3.0.12 and 3.0.13 releases are definately different. Does changing these keys in the web.config files back to the 3.0.12 values fix the login issue for you (those experiencing the problem after upgrade)?

 

Ok, that worked, I can now log in as admin, but not host. I get this "A critical error has occurred.
Input string was not in a correct format".  DNN told me to wait 10 minutes before trying my password again, so hopefully it will resolve itself. Otherwise it looks like things are working again.

Mark Garcia

The 3.0.13 where definitely different from 3.0.12.  it looks like you are only showing 3.0.12's above.  Can you triple check your web.config file.

the help desk wrote:

The 3.0.13 where definitely different from 3.0.12.  it looks like you are only showing 3.0.12's above.  Can you triple check your web.config file.

I have just checked by unzipping each web.config into separate dirs.  According to WinMerge and a visual check both files are identical.  Was there a later download of 3.0.13?

 

Declan

---------------------------------------------------------------------------------------------------------------------

DNN 3.0.13

Download dated April 4th 2005

Web.Config Dated April 3rd 2005

<add key="SiteSqlServer" value="Server=(local);Database=DotNetNuke;uid=;pwd=;" />

<add key="MachineValidationKey" value="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902" />

<add key="MachineDecryptionKey" value="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC" />

<add key="MachineValidationMode" value="SHA1" />

 

DNN 3.0.12

Download dated March 13th 2005

Web.Config Dated March 9th 2005

<add key="SiteSqlServer" value="Server=(local);Database=DotNetNuke;uid=;pwd=;" />

<add key="MachineValidationKey" value="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902" />

<add key="MachineDecryptionKey" value="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC" />

<add key="MachineValidationMode" value="SHA1" />

I was mistaken.  What you have is correct for the Machine Keys.  For some reason, mine where different than this.  Setting them to this made it function.

In DNN 3.0.13 we implemented a security enhancement for new installations which results in a change to the MachineKey settings in the web.config. The MachineKey settings are used by the MemberRole component for encrypting users passwords... but if every DNN installation was using the same MachineKey value, it really defeats the purpose of encrypting the passwords in the first place ( since they could easily be decrypted ).

To implement this feature, we needed to modify the auto upgrade logic significantly. On a new install ( determined by calling GetUpgradeStatus ), the application will perform a 2 stage install procedure. The first stage opens the web.config file, creates some random keys of the correct byte length using the CryptoRNG namespace, inserts these values into the MachineKey values in AppSettings, and saves the web.config. This action triggers an application re-start. When the application restarts, it still determines it is a new installation, so it proceeds to the second stage where it provisions the database, etc...

The logic to modify the MachineKey should never be happening on an upgrade unless the GetUpgradeStatus is returning the wrong result ( in which case I think there would be other problems as well since the clean installation scripts would be re-executed ). Anyways, to trouble shoot the problems in this thread, I would like to understand why the GetUpgradeStatus would return UpgradeStatus.Install for some people when it should be returning UpgradeStatus.Upgrade.

 

off the record ..  but is there a defect noting this change ..  otherwise people are unaware of such changes ..  not details but in general of course    :)  otherwise things like pop up after RC and people, maybe wrongly, might place this directly into production ..   and then not get a resolution for a day ..  

Is the install vs upgrade done by dnn.config  or by the table value or both??

GetUpgradeStatus checks for dnn.config in the /Install folder - if it exists then it reads the version number ( assume upgrade ). If it does not exist then it calls the database GetVersion method. If it returns a version number then it assumes upgrade otherwise it assumes a new installation.

Same thing here.

I forgot to re-enter the sql settings in Web.config when I first tried to do the upgrade. The cannot connect to DB error came up and a stuck my sql settings back in, then did the upgrade.  I happened to save my keys from the 3.0.12 config file, so I was able to drop those in and login without a hitch. 

Is it possible that on my first try with the blank sql info, it generated new keys thinking it was a new install?

-Liddy

Shaun, for those of us who encountered the problem (i normally run CSDiff to check web.config, just didn't this time..), if we reset the keys back to .12's values (which solved the issue), will we interfere with the newer security measures? thanks, drew..

sbwalker wrote:

.. but if every DNN installation was using the same MachineKey value, it really defeats the purpose of encrypting the passwords in the first place ( since they could easily be decrypted ).

Shaun,

Your point is good and suggests that many DNN users use the default keys, I included

This means that we now have user passwords encrypted with the default key.  How would you suggest we implement a change.  Am I correct in saying that if we just change the key then no one will be able to login. Is there some routine to allow for a change of key?

Declan

liffey wrote:

... Is there some routine to allow for a change of key?

Great question. Would be great to let the entire community know about this issue too. 

liddy - if you did not have a valid connection string and your dnn.config file was missing, then DNN would have assumed a new install. So in this case the application would have generated new machine keys in your web.config.

liffey,

Any 3.0.12 installation of DotNetNuke would have used the default MachineKey values ( because the issue was not identified until last week ). The only way to change the Machine Key values on upgrade would be to write a utility which allows you to enter the old machine key value and new machine key value - then the code would need to read all of the user accounts in the system, decrypt the password with the old key, encrypt the password with the new key, and save the user account. This is not something which can be accomplished as part of the auto upgrade process in DNN. But you also need to consider that in order to exploit this security issue, somebody would need to get unauthorized access to your DNN database... so the risk is not as high as it sounds. At least from 3.0.13 forward we have a mechanism in place on new installs which generates unique MachineKeys per install to further reduce the risk.

That is definitely the case in my scenario -

have 2 installs of 3.0.12 DNN1 and DNN2
delete the dnn.config in both
Overwrite both with 3.0.13 files including web.config
Change db connection correctly in DNN1  - incorrectly in DNN2
DNN1 install goes through upgrade process as intended
DNN2 install errors out (db connection). When I correct this DNN2 runs the new installation process instead of upgrade and the machine keys change. This then means that I can't login to DNN2 - copying the old machine keys back into web.config fixes this.

So the answer seems to be - it works as intended if DNN runs an upgrade rather than a new install. So save your old web.config file somewhere because you may need it!