which machineKey config is better?

Question

i 'm working on my web application security and want to know if i use this:

 <machineKey validationKey="AutoGenerate,IsolateApps" 
 compatibilityMode="Framework45"  decryptionKey="AutoGenerate,IsolateApps" 
 validation="SHA1"/>

in my web.config , now first user send first request to my site and in this time validationKey will be create and after that second user send second request now validationkey will be create again or what ?

and are the same these validations keys for all user ?

what is deference between that config and this?

<machineKey compatibilityMode="Framework45"  
 validationKey="37BAD4B702C65CF39B1ED514AC4B3D88990DDF784AA0895659
 B528ED95F8CA0A9CD1AF5ED92A2599362684CB8D204AC30D07E6BF0CF65194A5129" 
 decryptionKey="B450FB3271C49E6BA89A0C5C8D06B61875BCE4916A40474ED" 
 validation="SHA1" decryption="AES" />

which one is better to use?

Answer 1

AutoGenerate means that your key is auto generated once and then stored (by the Local Security Authority service) - in other words, it doesn't change between requests - in fact, it should never change on the same machine.

IsolateApps means each application (ETA: mostly, see below) gets its own validation/decryption key - rather than all applications on the machine sharing a single key. But still, the key is generated and then stored the first time it's needed, and will be reused for all subsequent requests.

Update 2017: ASP.NET 4.5 added IsolateByAppId, which adds further isolation compared to IsolateApps. IsolateApps creates a different key for each app based on it's virtual directory path. This means that if two apps on the same server have the same virtual path (e.g. /), only being distinguished by being hosted on different ports or host name, they'll still get the same key, even with IsolateAppsenabled. IsolateByAppId will create different keys based on the application's AppDomainAppID. (End of update)

However, if your application is hosted on a web farm, in the cloud, on a cluster, etc. - where requests may be processed by different machines, you'll need the key to be the same for all those machines - hence the pre-generated keys in your second example. Do remember that you need to generate these yourself (and generate them properly), rather than reusing someone else's.

Here's an easy way to generate the keys with IIS 7

ETA: To avoid link rot, here's a synopsis of the link above: IIS 7 and later includes machine key generation in the IIS Manager UI: Under Machine Key for your website (found in the ASP.NET section), you'll find a Generate Keys action in the actions panel. This uses the RNGCryptoServiceProvider to generate decryption and validation keys for you.

(Once upon a time, apparently the SQLMembershipProvider would complain about auto generated keys - but only in order to avoid the above issue if the application should end up not hosted on a single server).

Microsoft recommends using the default values if the above situation doesn't apply to you - i.e.:

• If your application is hosted on a single server: Use AutoGenerate,IsolateApps
• If your application is on a web farm/cloud service/clustered network: Use a manually generated key.

(You're also specifying "AES" as the decryption algorithm in the second example, but since AES is the default, that's not a difference between the two).

Update 2017: Why would I want to use IsolateApps (and/or IsolateByAppId)?

The question should really rather be, why wouldn't you? It's on by default. The reason being that a host without it and hosting multiple applications, every application would get the same key, which isn't the best scenario, if you're not in control of all applications (e.g. a shared host).

Does it have downsides (other than being useless for web farm/cloud/cluster)? Yeah, somewhat. IsolateApps will reduce the entropy of the dncryption key by 32 bits (from 192 bit to 160), because 32 bits of the key will be a hash of your virtual directory, which is known to an attacker (for example, if your app is at the root of the domain, those 32 bits will be 4e ba 98 b2. IsolateByAppId reduces it further by another 32 bits to 128 bits.

That leaves you with what (basically) amounts to 128 bit AES rather than 192 bit AES for the decryption key. Similarly, the validation key will be reduced from an entropy of 256 bits to 192 bits.

Disclaimer: The following paragraph is a dangerous thing to say in cryptography, so do research it further rather than trusting it if you're doing security critical work - and particularly if you're using the keys for data with information value beyond the next decade.

Anyway: If you don't know the implications of the above entropy reductions, those implications are unlikely to bite you. 128 bit security with AES and 192 bit entropy for the validation key (a hash) is, in 2017, more than "good enough". (Hence why this is not thoroughly documented in the first place). (End of update)