2

Our production servers all have the same machine key. However, our production and development systems do not have identical machine keys. We get heaps (about one per second) of exceptions of the form

System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
at System.Security.Cryptography.RijndaelManagedTransform.DecryptData()
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock()
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData()
at System.Web.UI.Page.DecryptStringWithIV()...

We deploy the code after a build, .cs source is not present on production. aspx files are present on production.

(Should I have posted in Stack Overflow? It's not a coding question.)

From experimentation, we've found using the dev machine key value causes the exceptions to go away. Does anyone have documentation that I can use with the security team on the need for identical keys at compile and deployment time?

Henry Troup
  • 43
  • 6
  • So it looks like you are decrypting some data. How was the data encrypted? – Jeff Apr 01 '10 at 23:32
  • Your machine key is set to a manual one right? You are not using auto generated machine keys right? – smoak Apr 16 '10 at 17:26

1 Answers1

2

The answer is no.

The reason for not using same machine keys is that developers should not see production environment secret keys. If you have an ex-workers or external consultants, you can't guarantee that they won't spread the development code to somewhere. In wrong hands, the keys make it easy to attack to the servers.

Here is a nice link.

Tuomas Hietanen
  • 138
  • 1
  • 9
  • But you can take the development key, keep the length and just change a few hex-characters. ;) – Tuomas Hietanen Jul 29 '10 at 21:49
  • The real problem was not this at all; backtracking from the logs showed that mutilated/mutated requests are been injected from the outside world. – Henry Troup Mar 26 '12 at 19:18