My ASP.NET MVC 4 website (hosted as an Azure web role) stores some sensitive data in a SQL Server table. When a user begins the workflow that generates the data, I get a random key from the Rijndael implementation and store it in the session state. I use that key for round trip encryption/decryption to and from the database throughout the life of the session. Thus, only code running in that session (or, at least, code that has access to the key stored in the session state) can decrypt the data.Now I have a need to allow the database records to hang around for a while and to access them from a different session. Since this session doesn't have access to the key stored in the previous session's state, it seems to me that my best, easiest course of action is probably to encrypt all of the data using a key that is baked into my application code.I should add that I'm trying hard to NOT use any Azure hooks so that my website can be hosted on any ASP.NET host.I have two questions:[*]Is my existing scheme (storing my key in session state) secure on Azure if my session state scheme is \[code\]<sessionState mode="StateServer" />\[/code\] and I am, in fact, using multiple hosts? (Please be kind... I'm still figuring out this whole ASP.NET/Azure thing. At the moment I'm using InProc session state; I haven't even tried to get the multiple host thing working yet.)[*]Using a random per-session key seems to be a stronger encryption scheme than using a single baked-in key. But, on the other hand, the whole SSL world is predicated on having all communications protected by a single private key baked into an SSL certificate. Should I be concerned about using a key baked into my code? Is there a better scheme - something akin to what I was doing using per-session keys?
Cryptography options
- Thread starter medway
- Start date