views:

358

answers:

6

Working inside the context of an ASP.NET application I am creating a page that will be able to execute database scripts against one of many databases in our environment. To do this we need to prompt the user for a username/password combination, this value can be used for all servers without issue.

The question is where is the most secure location to store this information? We need to store it temporarily as when they are on this specific page they could be executing hundreds of scripts, over multiple postbacks. From what I can tell I have 3 options and I'm not sure what is the best. Below is my take on the options, what is the recommendation of everyone here? What is the most secure, while still being friendly for the user?

Store Information In Viewstate

One of the first ideas we discussed was storing the information after being supplied by the user in the ViewState for the page. This is helpful as the information will only exist for the lifetime of the page, however, we are unsure of the security implications.

Store information in Session

The next idea we had was to store it in session, however, the downside to this is that the information can be made available to other pages inside the application, and the information always lingers in memory on the server.

Store Information in Application

The last idea that we had was to store it in the Application cache, with a user specific key and a sliding 5 minute expiration. This would still be available to other pages, however, it would ensure that the information is cached for a shorter period.

Why?

The final question that is important is "Why are you doing this?". Why don't we just use their Lan id's? Well we cannot use lan id's due to the lack of network support for delegation.

S0 what is the recommended solution? Why? How secure is it, and can we be?

Update

Great information has been discussed. TO clarify, we are running in an intranet environment, we CANNOT use Impersonation or Delegation due to limitations in the network.

+1  A: 

The ViewState approach is good but has the problem that you are giving out the username and password to the client. Even if you encrypt it, if some attacker has the encryption key, the situation will not be very good.

Regarding the Session and Application approaches, I don't think Application approach makes sense. Data is user specific, so Session should be the way to go. It'll go away as soon as user's session is closed. By the way, if you chose to store it at the server, use SecureString class.

Mehrdad Afshari
Great recommendation on the SecureString class!
Mitchel Sellers
+3  A: 

In my opinion the natural place for this is the Session.

I'm not sure why you seem to be fearing "other pages inside the application" (you control the appliciation, don't you?), but if you really are, you could use some sort of encryption before you store it.

But if you are going to do that, the data could live in the ViewState as well.

Tomalak
The concern is that we have a development team of 70 other developers that "could" touch other pages in the application. Granted a minimal risk, but still a risk.
Mitchel Sellers
Maybe place it in a class that gives out the info to the correct/expected caller page only.
Tomalak
+3  A: 

I don't like any of these ideas, but totally hate the viewstate idea.

I don't know how many databases you are attaching to, but if there is a limited number, I kind of wonder if handling your authentication and authorization in a standard secure manner, then connect to those databases via integrated security using identity impersonation with an account that has minimal permissions.

John MacIntyre
I agree 100%, I hate ALL of the ideas. But integrated security IS NOT AN OPTION in our environment.
Mitchel Sellers
A: 

Storing in Viewstate increases your exposure because the password will be flying around the internet again and again. It's up to you if encryption is good enough to address this risk.

Using Application or Session both keeps the password in the server. As mentioned above SecureString will keep people from simply reading passwords out of memory. Session will scale to more users, and probably more importantly to multiple servers much easier than Application. Unless you are sure you will never use more than 1 web server I would not use Application, as it will be up to you to synchronize all the servers.

ScottS
Good point on syncing. We are on a 2 web server interface, all intranet, no public transmission, with sticky sessions enabled on the load balancer.
Mitchel Sellers
+1  A: 

As John MacIntyre wrote you should use integrated security and impersonation for this.

If for some reason you can not use it and you are going to provide your own login page, use by all means SSL to encrypt the traffic between the browser and your server. Using the ViewState approach is also completely insecure if you do not use SSL, there are tools to view the contents very easily. From the methods that you enumerate the best one would be to use the Session state. You can offload saving the session state from your web server memory and save that data in a database that you can secure the way you want. If you don't like the way these work you could even write your own session state provider and apply the security you need there.

Alejandro Mezcua
As I commented to John - integrated security IS NOT AN OPTION in our environment. We are running over SSL for all communications with the server.
Mitchel Sellers
A: 

Never store passwords!

Rather store the hash of a password. See: http://en.wikipedia.org/wiki/Crypt_(Unix)#Library_Function.

I'm aware this does not answer the question, but the more programmers who ignore this advice, the easier it will be for criminals to steal data. Don't let your organization become a news story.

Jon Ericson
Yes, I understand that, but in this case I MUST keep a password, only in memory though.
Mitchel Sellers
You're the boss. But be aware that other people read questions and answers and may not be as savvy as yourself. Storing plaintext passwords for a nanosecond longer than necessary is a security flaw. (Memory can be hacked, you know.)
Jon Ericson
I know and agree 100%. The biggest thing is that since we are calling another process, we cannot work with hashes, we could encrypt/decrypt on the fly, but we have to be able to get the exact password back. Ideally we would just make it so we could use delegation and impersonation....but we cant.
Mitchel Sellers