A Word about Machine Keys


Since its inception, ASP.NET has allowed you to configure two cryptographic keys that control its validation and encryption of statelike the Forms authentication cookie, the hidden view state field in a Web form, and so on. By default, the <machineKey> element that controls this via configuration is set to AutoGenerate, which is why you may never have needed to think about it, unless you were implementing a Web farm. In a Web farm scenario, if Web server A issues state to a client that is encrypted with its autogenerated key, Web server B isn't going to be able to decrypt that state because its autogenerated key is going to be different. Generating a good, random key becomes important when you have a Web farm, and there are many tools available that can help you do it, including the ASP.NET Administration Console sample that comes with this book.

With the arrival of SqlMembershipProvider, the machine key becomes even more important. If you choose to store passwords encrypted with a key (see the earlier section titled Choosing a Password Format), it's critical that you choose that key yourself instead of allowing ASP.NET to autogenerate it. The reason for this is that if you lose the key, all of your user password verifiers become useless. With an autogenerated <machineKey>, moving your Web application from one Web server to another or reinstalling the operating system on your Web server would cause you to lose the ability to authenticate all of your users.

Because of this, if you choose Encrypted password storage, the SqlMembershipProvider will fail to initialize if you haven't explicitly chosen a <machineKey> (the ASP.NET team didn't want you to accidentally run with an autogenerated key and end up paying for it later!).

There's an unfortunate irony when it comes to cryptographic keys: the longer you use a key, the weaker it gets, and over time you're protecting more and more data with that same key, thus the damage potential (if the key is compromised) continues to increase over time as well. Any system that requires cryptographic keys should make it easy to change those keys on a regular basis; otherwise, you're effectively relying on hardcoded keys, which is bad news. Consider this: How comfortable are you going to feel when your system administrator quits and starts working for your competitor, potentially taking knowledge of your applications' secrets with her?

Sadly, <machineKey> doesn't ease the pain at all by making key versioning easy. For example, if you decide to swap out your key, you'll be in a real pickle if you're using Encrypted password storage (you'd need to write custom code to rekey those user password verifiers, for one thing). Also, any users with existing view state or forms login cookies will receive errors the next time they connect. So, assuming you aren't using the Encrypted password format, if you decide to change your <machineKey> settings in production, be sure not to do it during peak traffic time. I hope the ASP.NET team considers making key versioning a priority in the next release.

On the plus side, in ASP.NET 2.0 you have more control over the algorithms and key lengths used by <machineKey>. You can now generate a 256-bit encryption key that uses the Advanced Encryption Standard (AES), and that is exactly what you should do to ensure that your attackers don't even bother trying to crack the cryptography you're using. The ASP.NET Administration Console sample will create a strong key like this for you by default using the cryptographic random number generator that's provided by the Windows CryptoAPI.




Essential ASP. NET 2.0
Essential ASP.NET 2.0
ISBN: 0321237706
EAN: 2147483647
Year: 2006
Pages: 104

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net