Do ASP.NET Session[string key] data need to be encrypted to be secure?
If such data always stays on the server, doesn't that make it safe to store credit card information, passwords, etc. there, as long as the data were sent via SSL from the client?
A:
Depends -- how much do you trust every other app on your server?
Wyatt Barnett
2010-10-26 18:59:53
A:
No. You should never store this information in the session. Even encrypted this information is vulnerable. Sessions may get hijacked, a server may get compromised and then everything that is in memory that happens to be used in memory as plaintext will be viewable to anyone with a hex editor. If you need references to this information, you should create hashes that are stored and not replayable that reference the information in a secure datastore.
EDIT: For those that think session data is safe:
http://en.wikipedia.org/wiki/Session_hijacking
http://en.wikipedia.org/wiki/Session_fixation
http://en.wikipedia.org/wiki/Session_poisoning
http://www.owasp.org/index.php/2.0_Session_State_(in)security_(and_the_dangers_of_State_Server)
There are ways of protecting session data, but if you need to keep very sensitive information such as passwords or credit card numbers, the session is not the place for it. Try coding to the Sarbanes Oxley legal requirements for banking and medical applications, and you'll find in your first audit that this is one of the first things that gets checked.
Joel Etherton
2010-10-26 19:06:08
-1. A hash cannot be used as a reference because the original data is lost. What do you recommend doing with sensitive data? Whether its stored in a database or session either could be compromised via a session hijack.
m.edmondson
2010-10-26 19:54:19
@m.edmondson and @ Joel Ethertonboth of you have no idea how software is attacked. I took away my +1, session data is always safe, cookies are always unsafe.
Rook
2010-10-26 21:17:57
Without getting too involved, if you can't trust something simply because it's in memory, then how do you intend to do anything AT ALL? You must decrypt their credit card number to process it. It will be somewhere in memory in plaintext. I'm not arguing that a session couldn't theoretically be compromised slightly more easily just because it's likely to be around longer, but if we are to worry about "everything in memory" because the server could be hijacked completely it will be hard to accomplish much. There must be some basic assumption that "memory" is ok to use.
jamietre
2010-10-26 21:39:05
I agree @rook comments are a joke
m.edmondson
2010-10-26 22:41:34
@Rook - made edits with links just for you.
Joel Etherton
2010-10-27 11:31:31
@m.edmondson - the hash is just a reference to data kept in a secure store separate from the application itself. non-sensitive relational data + a timestamp embedded in an HMAC allow the application to access necessary data without storing it outside of its secure data store. There is no decryption involved in the transaction, just a comparison of hashes to access the data.
Joel Etherton
2010-10-27 11:35:34
@jamietre - We don't worry about "everything". We worry about the extremely sensitive information that would be the worst to have compromised. If data is compromised, no one cares if the person just got addresses or middle names. They do care if a collection of passwords or a list of credit card numbers with id relating data is released.
Joel Etherton
2010-10-27 11:38:27
@Joel as I said, in order to do anything useful you are going to have to have sensitive information in memory in plaintext, yes, along with ID relating information... since that is exactly what your customer typed into a form. You cannot process the transaction without this.
jamietre
2010-10-27 12:06:30
@jamietre - I agree with you at that point. But my point is that this information should never enter session (because through various means this data is remotely available). If you have someone with a hex editor reading memory on your server you have much bigger fish to fry.
Joel Etherton
2010-10-27 12:09:30
Actually, we could put this argument to rest if someone can just post a link to an incident where memory-based information was compromised on a server. Just rationally, the amount of effort, planning and skill that would be required to pull of something like that to steal... er... credit card data, it is impossible to fathom. If it's ever happened, I hope they stole nuclear launch codes.
jamietre
2010-10-27 12:11:28
@jamietre - I did it to a server at my local company to demonstrate how non-kerberos passwords on a windows server were available in resident memory through the use of a hex editor (in plain text). Here's a link to the hex editor I used - http://technology.ezinemark.com/download-hxd-hex-editor-1.7.7.0-free-168b76da3ca.html
Joel Etherton
2010-10-27 12:16:10
You should probably upgrade your server to one that incorporates memory protection, then. http://en.wikipedia.org/wiki/Memory_protection
jamietre
2010-10-27 12:24:35
@jamietre - that's a good read. Memory protection in that context only prevents write access from occurring. It doesn't prevent read access. A hex editor can still open and view the contents, it just can't make changes to active memory. Although I have to admit I've never tried to make changes to the memory directly. Some of those external links are pretty good too.
Joel Etherton
2010-10-27 12:33:36
I am no expert, but I am pretty sure that you would be unable to do this without the application being highly privileged. If your server was so compromised then that is the least of your concerns. I am not arguing it is impossible. Anything is possible. But if you had such access to the server, then why would you go to all this trouble, to monitor application memory waiting for a certain kind of information to appear? Why wouldn't you just, say, intercept the data being sent to the application in the first place? If you are actually at the point where this is a problem you're already screwed.
jamietre
2010-10-27 12:46:16
@jamietre - I'm not an expert either. I've got enough experience under my belt to get myself into trouble. I used a low level non-guest account to do it, so I don't know what level of privilege is necessary, but it's a technique that would seem to be usable to escalate privileges. I agree you'd already be screwed, but I would still say to keep passwords and credit cards out of the session.
Joel Etherton
2010-10-27 12:53:43
I agree that you shouldn't be persisting sensitive data this way in a web app. I can't think of a good reason to do it, and I think there could be other risks (such as ASP.NET bugs or exploits causing a session to be compromised, having nothing to do with memory management). It's just bad form. Yet I just can't imagine anyone actually bothering to do this. Every single record is available only for the life of a session. So much work for so little. It would be an astounding accomplishment to set up a harvester like this, and anyone who can do this should be stealing secrets from China.
jamietre
2010-10-27 13:06:25
@jamietre - tru dat :)
Joel Etherton
2010-10-27 13:14:06
what about session riding(csrf)?
Rook
2010-10-27 22:05:25
@Rook - what I'm supposed to list every session exploit out there? The point is/was/will be - sessions are not secure so don't store super sensitive information there.
Joel Etherton
2010-10-28 11:20:44
@Joel Etherton right but if someone hijacks the session then they are logged in as that person. Its a moot point.
Rook
2010-10-28 17:48:26
@Rook - It is far from being moot. If you don't store the sensitive data in the session then the attacker has to use other means to retrieve it. Good security practices would dictate that sensitive information (ssn/cc num/pw) shouldn't be displayed on any page. SSN and CC might have last 4 displayed but the rest ticked out. The point remains-keep sensitive information like this out of the session. In most cases, the true user already has this information; doesn't need to see it displayed again. Displaying it, holding it, etc only makes it available to attackers. it does not help the user.
Joel Etherton
2010-10-28 18:05:01
@Joel Etherton you must be clear about what you are defending against. because the vulnerabilities listed do not pertain to this type of impact.
Rook
2010-10-28 18:14:16
@Rook - I am not defending against anything. I'm saying the session is not a safe place to put sensitive information. You said "session data is always safe, cookies are always unsafe". I disagree. You're the security expert here, feel free to submit your own answer.
Joel Etherton
2010-10-28 18:17:46
@Joel Etherton security is defending against attacks. Session data stored in a file can be obtained via directory traversal and session data stored in the database can be obtained via sql injection. Session hijacking, session fixation and session riding has nothing to do with this. These attacks compromise a users account, which is often more valuable to the attacker.
Rook
2010-10-28 19:08:10
@Rook - My mistake. I misread your "defend against" statement context. I don't disagree with anything you just said, but I still maintain that sensitive data such as cc/pw/ssn should not be put into the session because that information is vulnerable to exposure. Even encrypted.
Joel Etherton
2010-10-28 20:06:21
@Joel Etherton I agree for the most part. But lets take one case into consideration. Credit Card numbers must always be encrypted if they are stored on the disk due to the PCI-DSS. Many session handlers will dump the data to the drive, for instance PHP does this. Where are you going to keep the key? Often times this is stored in config file on the disk, if you can read the session data you can read the key used to encrypt it. Moot point. Thats why i don't like this question, its not an encryption question. Session data is "safe" for secrets and you don't have a choice.
Rook
2010-10-28 23:09:31
+1
A:
Anything sensitive should go straight to the database, and not hang around in memory longer than needed. I don't understand why you'd need to store passwords or credit card data in session variables anyway, are you passing them between pages?
m.edmondson
2010-10-26 19:52:29
Thanks for the -1. Also memory is safer than a database because of sql injection. your -1 stays, now and until this post is fixed. As the point leader for security tags i recommend that you avoid this tag as much ass possible, someone will get hacked if you don't.
Rook
2010-10-26 20:10:34
I'm passing data between pages. You don't quite answer the question -- is encryption necessary, or not?
ChessWhiz
2010-10-26 21:10:26
@ChessWhiz - Encryption is not necessary whilst it is on the server. Any where during transit (you've handled this with HTTPS) or whilst stored anywhere (database, file) then yes it needs encrypted. I think that if an attacker managed to get deep into your system so that he could read the servers memory you're already in deep trouble.
m.edmondson
2010-10-26 21:18:13
I would say that it is much less secure to send the sensitive data to the database rather than keeping it in RAM!
Jay
2010-10-27 00:55:40
@Jay - Hence why it needs encrypted when stored in there, but not in RAM
m.edmondson
2010-10-27 08:15:57
+1
A:
With all the downvotes being thrown around here, I'll add my own two cents:
I think that anything that stays in server memory, including ASP.NET Session data, is safe in unencrypted form. An attacker would have to be able to execute code on the server in order to read the memory.
On a side note, once it's stored in a database, data should be encrypted. If it's sent to the client, it should also be encrypted, but that's outside the scope of this question. Lastly, of course, the data must be encrypted on its way from the client to the server.
ChessWhiz
2010-10-26 21:39:28
+1
A:
I share m.edmondson idea, in the fact that sensitive information should be stored in database, (there are many techniques to dealing with sql-injection). Also for securing your site you should use HTTPS. But if you're going to store information that is not so sensitive for passing between pages you can use session variables, don forget to delete such variables as soon as possible. Remember you can aver going to the database to retrieve the data, only non-sensitive and time-consuming data should be stored in session scope.
ArceBrito
2010-10-27 00:32:46