在处理过程中存储用户名/密码
在 ASP.NET 应用程序的上下文中工作，我正在创建一个页面，该页面将能够针对我们环境中的众多数据库之一执行数据库脚本。 为此，我们需要提示用户输入用户名/密码组合，该值可以毫无问题地用于所有服务器。
问题是存储这些信息最安全的位置在哪里？ 我们需要暂时存储它，因为当它们位于此特定页面上时，它们可能会在多次回发中执行数百个脚本。 据我所知，我有 3 个选择，但我不确定哪个是最好的。 以下是我对选项的看法，大家有什么建议？ 什么是最安全的，同时仍然对用户友好？
在 Viewstate 中存储信息
我们讨论的第一个想法是将用户提供的信息存储在页面的 ViewState 中。 这很有用，因为信息仅在页面的生命周期内存在，但是，我们不确定安全隐患。
将信息存储在会话中
我们的下一个想法是将其存储在会话中，但是，这样做的缺点是该信息可以提供给应用程序内的其他页面，并且信息总是徘徊在会话中服务器上的内存。
在应用程序中存储信息
我们的最后一个想法是将其存储在应用程序缓存中，并使用用户特定的密钥和滑动的 5 分钟过期时间。 这仍然可供其他页面使用，但是，它将确保信息的缓存时间较短。
为什么？
最后一个重要的问题是“你为什么要这样做？”。 我们为什么不直接使用他们的 LAN id 呢？ 由于缺乏对委派的网络支持，我们无法使用 LAN ID。
S0 推荐的解决方案是什么？ 为什么？ 它有多安全？我们能做到吗？
更新
已经讨论了很多信息。 需要澄清的是，我们在 Intranet 环境中运行，由于网络的限制，我们无法使用模拟或委派。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在我看来，最自然的场合就是会议。
我不确定为什么您似乎担心“应用程序内的其他页面”（您控制应用程序，不是吗？），但如果您确实担心，则可以在存储之前使用某种加密。
但如果您要这样做，数据也可以存在于 ViewState 中。
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.
我不喜欢这些想法，但完全讨厌视图状态想法。
我不知道您要附加多少个数据库，但如果数量有限，我想知道是否以标准安全方式处理您的身份验证和授权，然后使用身份通过集成安全性连接到这些数据库使用具有最低权限的帐户进行冒充。
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.
ViewState方法很好，但存在一个问题，即您将用户名和密码提供给客户端。 即使你加密了，如果某些攻击者掌握了加密密钥，情况也不会太好。关于
Session和Application方法，我认为Application方法没有意义。 数据是特定于用户的，因此Session应该是正确的选择。 一旦用户会话关闭，它就会消失。 顺便说一句，如果您选择将其存储在服务器上，请使用SecureString类。The
ViewStateapproach 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
SessionandApplicationapproaches, I don't thinkApplicationapproach makes sense. Data is user specific, soSessionshould 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, useSecureStringclass.正如 John MacIntyre 所写，您应该为此使用集成安全性和模拟。
如果由于某种原因您无法使用它并且您要提供自己的登录页面，请务必使用 SSL 来加密浏览器和服务器之间的流量。 如果不使用 SSL，使用 ViewState 方法也是完全不安全的，有一些工具可以非常轻松地查看内容。 从您列举的方法来看，最好的方法是使用会话状态。 您可以从 Web 服务器内存中卸载保存会话状态的任务，并将该数据保存在数据库，您可以按照您想要的方式保护其安全。 如果您不喜欢这些工作方式，您甚至可以编写自己的 会话状态提供商并在那里应用您需要的安全性。
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.
存储在 Viewstate 中会增加您的曝光率，因为密码会一次又一次地在互联网上传播。 加密是否足以解决此风险取决于您。
使用应用程序或会话都将密码保留在服务器中。 如上所述，SecureString 将防止人们简单地从内存中读取密码。 会话将扩展到更多用户，可能更重要的是扩展到多个服务器比应用程序更容易。 除非您确定您永远不会使用超过 1 个 Web 服务器，否则我不会使用应用程序，因为同步所有服务器将由您决定。
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.
切勿存储密码！
而是存储密码的哈希值。 请参阅：http://en.wikipedia.org/wiki/Crypt_(Unix)#库函数。
我知道这并不能回答问题，但是忽略此建议的程序员越多，犯罪分子就越容易窃取数据。 不要让您的组织成为新闻报道。
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.
用户名/密码确实不应该存储在任何地方。
您存储实时数据库连接，最好来自会话对象中的池。 您只需要登录数据库所需的用户名/密码即可。
虽然另一个页面可以使用实时连接，但它不会像您通过存储用户名/密码那样向其他任何人提供对数据库的永久访问权限。
The username/password really shouldn't be stored anywhere.
You store a live database connection, preferably from a pool in your Session object. You only need the username/password as long as it takes to log into the database.
While another page can use the live connection, it doesn't give anyone else permanent access to the database as you would by storing a username/password.