My existing users are now getting errors when they try to login in (front end). I have done some reading around and one the likely causes is a miss match between the hashing algorithm on the machine key and membership.
<membership ... hashAlgorithmType="SHA1">
What is the default hashAlgorithmType for the Umbraco membership provider?
You have to use the same machine key on all of your environments, I believe it has used in the salting of the password and therefore can't authenticate (the password is converted to a hashed and salted one to compare it to there password on the database).
Thanks Sebastiaan for your reply. I know why the machine key is used, and it's for exactly this reason we are implementing it. My issue I am having is that once I have added a machine key, users are getting this exception
System.Web.Mvc.HttpAntiForgeryException (0x80004005): The anti-forgery token could not be decrypted. If this application is hosted by a Web Farm or cluster, ensure that all machines are running the same version of ASP.NET Web Pages and that the <machineKey> configuration specifies explicit encryption and validation keys. AutoGenerate cannot be used in a cluster.
at System.Web.Helpers.AntiXsrf.AntiForgeryTokenSerializer.Deserialize(String serializedToken)
at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext)
at System.Web.Mvc.ControllerActionInvoker.InvokeAuthorizationFilters(ControllerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor)
at System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName)
at System.Web.Mvc.Controller.<>c__DisplayClass1d.<BeginExecuteCore>b__19()
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass1.<MakeVoidDelegate>b__0()
at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.Mvc.MvcHandler.<>c__DisplayClass8.<BeginProcessRequest>b__3(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
It would seem there is an issue decrypting the values in the __RequestVerificationToken. If I delete this cookie, you can continue using the site as normal. However this is not really a fix for the rest of the user base.
Once you've added a machine key, you generally cannot just change it since this changes the entire way that .Net deals with Encryption/Decryption/Hashing for your site.
In 6.2, the membership providers have been upgraded to have a better approach to password security which is more inline with how .Net works with their built in membership providers which by default is HMACSHA256. Previous to 6.2, the membership providers don't salt the passwords and don't adhere to the algorithm specified in your web.config (unfortunately). The old membership providers used HMACSHA1 by defaut.
Both HMACSHA256 and HMACSHA1 are derivatives of KeyedHashAlgorithm... and the 'key' is controlled by your machine key. Thus, you cannot just change it. Just like once you have members that have stored hashed passwords, you cannot just go changing the hash algorithm since the hashes will come out differently.
Thanks for the reply Shannon. Any idea why I would get the exception above when I introduce a machine key to my Umbraco site? I haven't had one previously and now the introduction of one is causing the issue described above.
Am I using the wrong Hash Algorithm for my decryptionKey and validationKey values?
We have had a reasonably vanilla umbraco site that has now grown, it has around 10,000 members. We don't currently have a machine key.
We are now looking to but our site in a load balanced environment, ergo we need a machine key. Would we need to reset everyone's passwords or is there a better way?
Correct, but you'd have to be careful with your administrator's passwords too - You'll have to log in as the admin so you have a valid auth cookie, then add your machine key, then while your still logged in, go and change your password so it is now stored correctly. If you have a lot of user's you'll probably have to reset their passwords and manually distribute them to your users, or manually set them.
Changing a machine key is certainly not an easy thing to do. For members, you of course have a few options like:
Write a script to reset everyone's password, send out an email to everyone about it the change and include their new password
If you don't want to include the password in an email, you could send an email with a custom unique link for each member that displays a custom reset password form (you'd of course have to validate the unique link/id)
Okay, that all makes sense, I just have one more question as something isn't adding up for me. I have in the past forgotten admin passwords on small Umbraco sites which don't have a machine key. I have successfully copied across a hashed password from another Umbraco site into the user table and then logged in.
It would appear in that instance the passwords were the same value. How is that possible if IIS generates a key, as one is not specified, yet the hashed value was the same for the two users?
Most of the info is in part one under "A brief digression: auto-generated machine keys"
"If an auto-generated key is used, the runtime will automatically populate the registry key HKCU\Software\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeyV4 with a random number generated by a cryptographically-secure RNG"
"the auto-generated machine key is unique per user (where the user is usually the Windows identity of the worker process) on a given machine. If two web applications are deployed on a machine, and if those applications' process identities are equivalent, then the auto-generated keys will be the same for both applications."
"If no explicit hex key is specified in an application's configuration file, then the runtime assumes a default value of AutoGenerate,IsolateApps. Thus by default the user's auto-generated machine key is transformed with the application's virtual path, and this transformed value is used as the cryptographic key material."
I have a site that was developed locally and was, today, deployed on a shared hosting server where AutoGenerate keys do not work. I believe this is causing me to be logged out within seconds of being logged in. I have already verified that there is no server time discrepancy going on. I tried adding a fixed machine key but this caused my current password hashes to fail and due to the instant logouts I wasn't able to sneak a machine key in while using the old auth token.
The site currently only has two registered users so I'm not worried about a use case where I have to send out a bunch of passwords.
Just thinking out loud here for others that might be facing the same issue.
If you have the machine key installed and are getting logged out to quick to change it ..
Install your Machine Key in the web config.
Copy the AdminPasswordResetDLL in to your bin folder.
Start your site - so now you should be able to reset the admin user with a properly encrypted password.
Remember this is encryption and all of your users passwords are encrypted with whatever the original key was .. SO IF YOU HAVE USERS and don't want them to be locked out .. don't ADD OR CHANGE the MachineKey.
Perhaps you can set your password format to Plain text in your web.config, then have a look in your database for what is stored for your password. Then login using that hashed password, this will give you a working auth cookie ticket. Then you could change the config back to hashed and you should remain logged in. Then you can reset the passwords for your users/members.
Since your shared hosting setup must have some other config than the default, I'd advise that you should add a custom machine key to your site which is used across dev/staging/live if you are syncing your database between these installs. Then you can try to perform the above on your dev server first, then push to your shared hosting once it's working with your custom machine key.
Researching that caused me to look at the Machine Key setting in IIS - which had been set to allow two other apps to share a single signon.
Because of that, IIS had inserted the
Thankfully, it's not load balanced, so i was able to comment that key out and the problem went away. Now at least I understand what was going on - the password issue makes sense.
For me, I was able to overcome the error by removing the ,IsolateApps string from the decryptionKey and the validationKey. I now understand that this is only required in instances where you are using an automatically generated key.
You having removed the ,IsolateApps now means that you just specified an encryption value of AutoGenerate which means that all you items is getting encrypted/decrypted using this string. This is not very secure :)
I'm a little confused about machineKeys also; we haven't used or needed any before (just a single site on our own locally-hosted Win2008 server), but after a recent Nuget upgrade to 7.5.3, the trace log shows the following error. So we created a machineKey via IIS which got added to web.config, but then that kept our BackOffice/ActiveDirectory logins from working, so we removed it again.
ERROR Umbraco.Web.WebApi.Filters.AngularAntiForgeryHelper - Could not validate XSRF token
System.Web.Mvc.HttpAntiForgeryException (0x80004005): The anti-forgery token could not be decrypted. If this application is hosted by a Web Farm or cluster, ensure that all machines are running the same version of ASP.NET Web Pages and that the <machineKey> configuration specifies explicit encryption and validation keys. AutoGenerate cannot be used in a cluster.
at System.Web.Helpers.AntiXsrf.AntiForgeryTokenSerializer.Deserialize(String serializedToken)
at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext, String cookieToken, String formToken)
at Umbraco.Web.WebApi.Filters.AngularAntiForgeryHelper.ValidateTokens(String cookieToken, String headerToken)
Your Active Directory Logins are being authenticated via Active Directory and encrypting those via the machine key does not make sense. As the encrypted version is not what is in Active Directory. Active Directory has its own encrypted version.
Adding a machine key to Umbraco site
I am in the process of integrating another .NET application with my Umbraco 6.1.6 site. I have recently added a machine key to my web.config
My existing users are now getting errors when they try to login in (front end). I have done some reading around and one the likely causes is a miss match between the hashing algorithm on the machine key and membership.
What is the default
hashAlgorithmTypefor the Umbraco membership provider?Thanks in advance!
You have to use the same machine key on all of your environments, I believe it has used in the salting of the password and therefore can't authenticate (the password is converted to a hashed and salted one to compare it to there password on the database).
Thanks Sebastiaan for your reply. I know why the machine key is used, and it's for exactly this reason we are implementing it. My issue I am having is that once I have added a machine key, users are getting this exception
It would seem there is an issue decrypting the values in the __RequestVerificationToken. If I delete this cookie, you can continue using the site as normal. However this is not really a fix for the rest of the user base.
I'll ping Shannon, think you might need to do something like this:
http://stackoverflow.com/a/23402375/5018
Thanks Sebastiaan that is appreciated. Looked at the article and his issue is different from mine as I am adding proper generated keys
It's like the introduction of a fixed key is causing a whole host of signing in issues!
Once you've added a machine key, you generally cannot just change it since this changes the entire way that .Net deals with Encryption/Decryption/Hashing for your site.
In 6.2, the membership providers have been upgraded to have a better approach to password security which is more inline with how .Net works with their built in membership providers which by default is HMACSHA256. Previous to 6.2, the membership providers don't salt the passwords and don't adhere to the algorithm specified in your web.config (unfortunately). The old membership providers used HMACSHA1 by defaut.
Both HMACSHA256 and HMACSHA1 are derivatives of KeyedHashAlgorithm... and the 'key' is controlled by your machine key. Thus, you cannot just change it. Just like once you have members that have stored hashed passwords, you cannot just go changing the hash algorithm since the hashes will come out differently.
Thanks for the reply Shannon. Any idea why I would get the exception above when I introduce a machine key to my Umbraco site? I haven't had one previously and now the introduction of one is causing the issue described above.
Am I using the wrong Hash Algorithm for my
decryptionKeyandvalidationKeyvalues?Sorry, I should re-state that: You cannot add or change a machine key once you have members/users
A machine key is generated at runtime when you don't explicitly have one declared which is based on your applications path "/".
Okay, this is our situation right now.
We have had a reasonably vanilla umbraco site that has now grown, it has around 10,000 members. We don't currently have a machine key.
We are now looking to but our site in a load balanced environment, ergo we need a machine key. Would we need to reset everyone's passwords or is there a better way?
Cheers
Correct, but you'd have to be careful with your administrator's passwords too - You'll have to log in as the admin so you have a valid auth cookie, then add your machine key, then while your still logged in, go and change your password so it is now stored correctly. If you have a lot of user's you'll probably have to reset their passwords and manually distribute them to your users, or manually set them.
Changing a machine key is certainly not an easy thing to do. For members, you of course have a few options like:
Okay, that all makes sense, I just have one more question as something isn't adding up for me. I have in the past forgotten admin passwords on small Umbraco sites which don't have a machine key. I have successfully copied across a hashed password from another Umbraco site into the user table and then logged in.
It would appear in that instance the passwords were the same value. How is that possible if IIS generates a key, as one is not specified, yet the hashed value was the same for the two users?
Because as I mentioned the machine key is generated based on your applications path, which generally is always "/"
Some light reading to try to understand the process:
Most of the info is in part one under "A brief digression: auto-generated machine keys"
"If an auto-generated key is used, the runtime will automatically populate the registry key HKCU\Software\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeyV4 with a random number generated by a cryptographically-secure RNG"
"the auto-generated machine key is unique per user (where the user is usually the Windows identity of the worker process) on a given machine. If two web applications are deployed on a machine, and if those applications' process identities are equivalent, then the auto-generated keys will be the same for both applications."
"If no explicit hex key is specified in an application's configuration file, then the runtime assumes a default value of AutoGenerate,IsolateApps. Thus by default the user's auto-generated machine key is transformed with the application's virtual path, and this transformed value is used as the cryptographic key material."
Shannon,
I have a site that was developed locally and was, today, deployed on a shared hosting server where AutoGenerate keys do not work. I believe this is causing me to be logged out within seconds of being logged in. I have already verified that there is no server time discrepancy going on. I tried adding a fixed machine key but this caused my current password hashes to fail and due to the instant logouts I wasn't able to sneak a machine key in while using the old auth token.
The site currently only has two registered users so I'm not worried about a use case where I have to send out a bunch of passwords.
Any advice you can provide would be great.
Thanks,
Jason
Just thinking out loud here for others that might be facing the same issue.
If you have the machine key installed and are getting logged out to quick to change it ..
Install your Machine Key in the web config. Copy the AdminPasswordResetDLL in to your bin folder.
Start your site - so now you should be able to reset the admin user with a properly encrypted password.
Remember this is encryption and all of your users passwords are encrypted with whatever the original key was .. SO IF YOU HAVE USERS and don't want them to be locked out .. don't ADD OR CHANGE the MachineKey.
Hrm,
Perhaps you can set your password format to Plain text in your web.config, then have a look in your database for what is stored for your password. Then login using that hashed password, this will give you a working auth cookie ticket. Then you could change the config back to hashed and you should remain logged in. Then you can reset the passwords for your users/members.
Since your shared hosting setup must have some other config than the default, I'd advise that you should add a custom machine key to your site which is used across dev/staging/live if you are syncing your database between these installs. Then you can try to perform the above on your dev server first, then push to your shared hosting once it's working with your custom machine key.
I encountered this problem slightly differently - took a local dev version of 7.2.8 from Windows 7 to the production server on Windows 2012R2.
Admin user could enter data but never left the login screen.
App_Data/Logs showed: 10:45:40,406 [847] ERROR Umbraco.Web.Scheduling.ScheduledPublishing - [P4204/T1/D4] Failed (at "http://pilgrims.com:85/umbraco"). System.Configuration.ConfigurationErrorsException: Decryption key specified has invalid hex characters. (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config line 390)
Researching that caused me to look at the Machine Key setting in IIS - which had been set to allow two other apps to share a single signon.
Because of that, IIS had inserted the
Thankfully, it's not load balanced, so i was able to comment that key out and the problem went away. Now at least I understand what was going on - the password issue makes sense.
For me, I was able to overcome the error by removing the
,IsolateAppsstring from thedecryptionKeyand thevalidationKey. I now understand that this is only required in instances where you are using an automatically generated key.Hi Simon.
As far as i can read from the https://msdn.microsoft.com/en-us/library/w8h3skw9(v=vs.85).aspx
You having removed the ,IsolateApps now means that you just specified an encryption value of AutoGenerate which means that all you items is getting encrypted/decrypted using this string. This is not very secure :)
You can go to http://www.allkeysgenerator.com/Random/ASP-Net-MachineKey-Generator.aspx to get a generated key
I'm a little confused about machineKeys also; we haven't used or needed any before (just a single site on our own locally-hosted Win2008 server), but after a recent Nuget upgrade to 7.5.3, the trace log shows the following error. So we created a machineKey via IIS which got added to web.config, but then that kept our BackOffice/ActiveDirectory logins from working, so we removed it again.
Your Active Directory Logins are being authenticated via Active Directory and encrypting those via the machine key does not make sense. As the encrypted version is not what is in Active Directory. Active Directory has its own encrypted version.
is working on a reply...