Saving username / password during processing

Question

Working inside the context of an ASP.NET application, I create a page that can execute database scripts on one of the many databases in our environment. To do this, we need to ask the user for a combination of username and password, this value can be used for all servers without problems.

The question is, where is the safest place to store this information? We need to temporarily store it, as if they were on this particular page, they could execute hundreds of scripts using several postbacks. From what I can say, I have 3 options, and I'm not sure which is better. Below is my selection of options, what is the recommendation for everyone here? What is the safest, albeit user friendly?

Store Information in Viewstate

One of the first ideas we discussed was to store information after a user provides it to the ViewState for the page. This is useful because the information will only exist throughout the life of the page, but we are not sure about its consequences.

Save Session Information

The next idea that we had was to save it in a session, but the disadvantage of this is that the information may be available for other pages within the application, and the information is always delayed in memory on the server.

Save information in the application

The last idea we had was to store it in the application cache, with a specific user key and a 5-minute rolling expiration. It will still be available for other pages, but it will provide caching information for a shorter period.

Why?

Last important question: "Why are you doing this?". Why don't we just use their Lan id? Well, we cannot use lan id due to lack of network support for delegation.

S0 What is the recommended solution? What for? How safe is it, and can we be?

Update

A lot of information has been discussed. To clarify, we work in an intranet environment, we CANNOT use impersonation or delegation due to network restrictions.

Answer 1

In my opinion, the session is a natural place for this.

I'm not sure why you seem to be afraid of “other pages within the application” (you control the application, right?), But if you really are, you can use some kind of encryption before storing it.

But if you are going to do this, the data can also live in ViewState.

Answer 2

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

I don’t know how many databases you are connecting to, but if there is a limited number, I wonder if you manage your authentication and authorization in a standard way, then connect to these databases through integrated security using personalization of an account with an account with minimal permissions.

Answer 3

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

As for the Session and Application approaches, I don't think the Application approach makes sense. Data is user-specific, so Session must be a transition method. It will disappear as soon as the user session is closed. By the way, if you decide to save it to the server, use the SecureString class.

Answer 4

As John MacIntyre writes, you should use integrated protection and impersonation for this.

If for some reason you cannot use it and you are going to provide your own login page, use SSL to encrypt traffic between the browser and your server. Using the ViewState approach is also completely unsafe if you are not using SSL, there are tools for viewing content very simply. Of the methods you list, it is best to use session state. You can disable saving session state from your web server memory and save data in the database , which you can protect the way you want. If you don't like the way it works, you can even write your own session state provider and apply the protection you need.

Answer 5

Saving to Viewstate increases your exposure because the password will fly over the Internet over and over again. It is up to you if encryption is sufficient to eliminate this risk.

Using an application or session maintains a password on the server. As mentioned above, SecureString will make people just read passwords from memory. The session will scale for more users and probably more important for multiple servers is much simpler than the application. If you are not sure that you will never use more than one web server, I would not use the application, since you will need to synchronize all the servers.

Answer 6

Never store passwords!

Rather, save the password hash. See: http://en.wikipedia.org/wiki/Crypt_(Unix)#Library_Function .

I know this does not answer the question, but the more programmers ignore this advice, the easier it will be for criminals to steal data. Do not let your organization become news.

Answer 7

The username / password really should not be stored anywhere.

You maintain a connection to the active database, preferably from the pool in the Session object. You only need a username / password if you need to enter the database.

While another page can use a live connection, it does not give anyone permanent access to the database, like you, by storing username / password.