[SOLVED] Isn't a constant validation key a security risk?

Isn't a constant validation key a security risk?

Today I learned that on server farms, I must not use validationKey="AutoGenerate", but specify a 'fixed' string value for validationKey, for consistency across request handling by the farm servers. The example given was:

<machineKey  
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7
               AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"           
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>

I was under the impression that the generation of a new key for every request and every user enhanced security quite a bit, but if the key is constant, it be retrieved from the hidden field on a form and used in a forged request.

Or must I cease using hidden fields for this key when on a server farm and use a header or cookie instead?

I say the anti-forgery key is stored in the form because this Razor markup:

@Html.AntiForgeryToken()

renders this HTML:

<input name="__RequestVerificationToken" type="hidden" value="bH6_-oZcRMuC9tA13RrOzmr0N3sWrzgkjKOhg2igHs5K2-G0HbJbF3KaK-QMrUDcQTXFbHJ-HFMNn9AjvF-TkAuBFo5f8Afi8q0OHXBzOTI1">

Unless we are talking about different keys here, but how would that work?

Solution

No, it's not a security risk.

The autogenerated key is not sent in a hidden field in the form, it's stored in the Local Security Authority (LSA) on the server (ref). If the key was sent in the form then there would be no need to have the same key on multiple servers. There would also not be any need to retrieve a key to forge a request, you could just send whatever key you wanted in a request.

With autogeneration the server doesn't generate a new key for each request, it generates a key for the server (or for the application if the IsolateApps option is used). It's only the message authentication code (MAC) that is generated for each request.