Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
So it looks like you are decrypting some data. How was the data encrypted? –  Jeff Apr 1 '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
add comment

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.