MSDN : machineKey
Configures algorithms and keys to use for encryption, decryption, and validation of forms-authentication data and view-state data, and for out-of-process session state identification
Specifically which methods in FormsAuthentication make use of validationKey and encryptionKey values?
The methods in FormsAuthentication that use validationKey and encryptionKey are the FormsAuthentication.Encrypt and FormsAuthentication.Decrypt methods.
Related
I have a client who wants to turn on ViewState encryption in an ASP.NET Web Forms application. They are not able to use the default algorithms because of FIPS compliance. The initial request from the client was to use 3DES/AES as follows, which I added to the web.config file:
<machineKey validationKey="..." decryptionKey="..." validation="3DES" decryption="AES" />
Putting in this configuration caused the application to stop working with the following error:
[HttpException (0x80004005): Unable to validate data.]
System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo, Boolean useLegacyMode, IVType ivType, Boolean signData) +1090
System.Web.UI.Page.EncryptString(String s, Purpose purpose) +150
[...]
By switching both keys to 3DES, I was able to get the system working.
Why does the system fail when the two different algorithms are used?
Not quite sure why that's failing - perhaps some error with the length of the key provided? The inner exception should be able to tell you more if there's one present.
Regardless, you should be aware that 3DES is being phased out by NIST and that ASP.NET does not use 3DES in a FIPS-compliant fashion. (Reference: http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf. See in particular the foreword, which states that we're in a transitional period for customers to move off of 3DES and on to AES. Also see Section 3.5; ASP.NET does not limit the number of invocations of the block cipher algorithm, so our particular usage of this algorithm makes it non-FIPS-compliant.)
The best course of action would be to use AES for encryption / decryption and HMACSHA256 for validation. This combination is FIPS-compliant and provides better security than 3DES / SHA1 (which is what was being used earlier). To do this, set:
<machineKey validation="HMACSHA256" validationKey="256 bits worth of hex digits (64 hex chars)" decryption="AES" decryptionKey="256 bits worth of hex digits (64 hex chars)" />
Then also set <pages viewStateEncryptionMode="Always" /> in Web.config to tell ASP.NET to use view state encryption using the algorithms you just provided in the <machineKey> element.
I try to read / decrypt the value of an auth cookie from forms authentication that is written in AES but without setting the MachineKey in the web.config because I cannot modify this config myself.
Therefore I can't use FormsAuthentication.Decrypt because this uses the machine key internally.
You didn't specify the ASP.NET version but in 2.0 and I think still in 4.0, you can override the machineKey in your web.config.
Check out the section "Web Farm Deployment Considerations".
http://msdn.microsoft.com/en-us/library/ff649308.aspx#paght000007_webfarmdeploymentconsiderations
You can generate a machine key online with this tool: http://aspnetresources.com/tools/machineKey
If the machine.config file does not define any section, nor does any web.config file, does it default to AutoGenerate option?
Thanks
Vikas
Yes, the AutoGenerate setting is the default setting for both decryptionKey and validationKey.
"AutoGenerate, IsolateApps" - Specifies that the key is automatically generated. This is the default value. The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA). The IsolateApps modifier specifies that ASP.NET generates a unique encrypted key for each application using the application ID of each application.
Source: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx
Is it possible to have both encypted and unencrypted connection strings in the same web.config?
I don't believe that you can encrypt an individual connection string as part of the ConnectionStrings section. This is because ConfigurationElement objects (ConnectionStringSetting derives from) has an ElementInformation Property which does not have a Protect method. A ConfigurationSection has a SectionInformation Property which does have a Protect method, ConnectionStringsSection inherits from ConfigurationSection.
So, with that said, you can encrypt a ConnectionStringsSection, but not a ConnectionStringSetting.
However, all is not lost. You do have the ability to create your sections/elements to maintain your non-encrypted (or encrytped depending on which way you want to go) connection strings. You just won't be able access them using the WebConfigurationManager's ConnectionStrings Property.
Why is it that I see the same hash value generated when I use different algorithms for viewstate encryption.
I have added below lines to the web.config file
pages viewstateEncryptionMode="Always" enableViewStateMac="true".../>
machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="AES" decryption="Auto" />
Also, compilation debug="false" ... > is set.
No matter what I use (AES, MD5, SHA1, 3DES), it generates the same hash. Is there something I am missing out.
Please let me know.
-Thanks
Here is an article on Encrypting Viewstate. It's for ASP.Net 2.0. which should be fine for 3.5.
Via P&P on MSDN:
Forms authentication defaults to SHA1
for tamper proofing (if or
,
then forms authentication hashes the
forms authentication ticket by using
either MD5 or HMACSHA1 (HMACSHA1 is
used even if validation is set to AES
or 3DES). Forms authentication then
encrypts the ticket using the
algorithm specified in the decryption
attribute. (The decryption attribute
was introduced in ASP.NET 2.0.)
Therefore, theoretically, only SHA1 and MD5 should differ in the hash that is produced.