AutoGenerate means that your key is automatically generated once and then saved (by the local security service), in other words, it does not change between requests - in fact, it should never be changed on one computer.
IsolateApps means that each application (ETA: basically, see below) gets its own verification / decryption key, and not all applications on the machine sharing the same key. But still, the key is generated and then stored for the first time when it is needed, and will be reused for all subsequent requests.
2017 Update : ASP.NET 4.5 IsolateByAppId , which adds additional isolation compared to IsolateApps . IsolateApps creates a different key for each application based on its path to the virtual directory. This means that if two applications on the same server have the same virtual path (for example, / ) that differ only in that they are located on different ports or the host name, they will still receive the same key, even with IsolateApps enabled, IsolateByAppId will create different keys based on the AppDomainAppID application. (End of update)
However , if your application is hosted on a web farm, in the cloud, on a cluster, etc. - where requests can be processed on different machines, you will need the same key for all these machines - therefore, the pre-generated keys in your second example. Remember that you need to generate them yourself (and generate them properly), and not reuse others.
Here is an easy way to generate keys using IIS 7
ETA: To avoid rotting links, here is a brief overview of the links above: IIS 7 and later include creating a machine key in the IIS Manager interface: under Machine Key for your website (see ASP.NET), you will find the action Generate Keys in the action bar. This uses RNGCryptoServiceProvider to generate decryption and validation keys for you.
(After some time, it seems that SQLMembershipProvider will complain about automatically generated keys, but only in order to avoid the aforementioned problem if the application is not hosted on the same server).
Microsoft recommends using the default values if the above situation does not apply to you - i.e.:
- If your application is hosted on the same server: use
AutoGenerate,IsolateApps - If your application is on a web farm / cloud service / cluster network: use a manually generated key.
(You also specify "AES" as the decryption algorithm in the second example, but since AES is the default, this is not the difference between the two). A.
Update 2017: Why do I want to use IsolateApps (and / or IsolateByAppId)?
The question really should be, why not? He is the default. The reason is that a host without it and hosting multiple applications, each application will receive the same key, which is not the best scenario if you do not control all applications (for example, a shared host).
Does it have flaws (besides being useless for a web farm / cloud / cluster)? Yes, a few. IsolateApps will reduce the entropy of the dncryption key by 32 bits (from 192 bits to 160), because 32 bits of the key will be a hash of your virtual directory that is known to the attacker (for example, if your application is in the root of the domain, these 32 bits will be 4e ba 98 b2 . IsolateByAppId reduces it by another 32 bits to 128 bits.
This leaves you with (mostly) 128 bits of AES, not 192 bits of AES for the decryption key. Similarly, the verification key will be reduced from entropy from 256 bits to 192 bits.
Disclaimer: The next paragraph is dangerous for cryptography, so study it further, and do not trust it if you are doing critical work in security - and especially if you are using keys for data with information value over the next decade.
In any case: if you do not know the consequences of the aforementioned reductions in entropy, these consequences are unlikely to bite you. 128-bit security with AES and 192-bit entropy for the verification key (hash) in 2017 is more than “good enough”. (Hence, why this is not fully documented in the first place). (End of update)