在处理过程中存储用户名/密码

时间:2009-01-16 16:58:20

标签: asp.net security application-security

在ASP.NET应用程序的上下文中工作我正在创建一个页面,该页面能够针对我们环境中的众多数据库之一执行数据库脚本。为此,我们需要提示用户输入用户名/密码,此值可以毫无问题地用于所有服务器。

问题是存储此信息的最安全位置在哪里?我们需要暂时存储它,就像它们在这个特定页面上一样,它们可以通过多个回发执行数百个脚本。据我所知,我有3种选择,我不确定什么是最好的。以下是我对选项的看法,这里的每个人的建议是什么?什么是最安全的,同时仍然对用户友好?

在Viewstate中存储信息

我们讨论的第一个想法之一是在用户在ViewState中为页面提供信息之后存储信息。这很有用,因为信息仅在页面的生命周期内存在,但是,我们不确定安全隐患。

在会话中存储信息

我们接下来的想法是将它存储在会话中,但是,缺点是信息可以提供给应用程序内的其他页面,并且信息总是在服务器的内存中徘徊。

在应用程序中存储信息

我们最后的想法是将它存储在应用程序缓存中,使用用户特定的密钥和5分钟的滑动过期。这仍然可用于其他页面,但是,它将确保信息的缓存时间更短。

为什么吗

最重要的问题是“你为什么要这样做?”。为什么我们不使用他们的Lan id?好吧,由于缺乏对委派的网络支持,我们无法使用lan id。

S0推荐的解决方案是什么?为什么?它有多安全,我们可以吗?

更新

讨论了很多信息。为了澄清,我们在Intranet环境中运行,由于网络的限制,我们不能使用模拟或委托。

7 个答案:

答案 0 :(得分:3)

在我看来,这是一个自然的地方。会议。

我不确定为什么你似乎害怕“应用程序中的其他页面”(你控制了应用程序,不是吗?),但如果你真的是,你可以在存储之前使用某种加密它

但如果您要 ,那么数据也可以存在于ViewState中。

答案 1 :(得分:3)

我不喜欢这些想法,但完全讨厌观点的想法

我不知道您要附加多少个数据库,但如果数量有限,我会怀疑是否以标准安全方式处理您的身份验证和授权,然后通过集成连接到这些数据库使用身份模拟的安全性与权限最小的帐户。

答案 2 :(得分:1)

ViewState方法很好但有问题是您要向客户端提供用户名和密码。即使您加密它,如果某些攻击者拥有加密密钥,情况也不会很好。

关于SessionApplication方法,我认为Application方法不合理。数据是特定于用户的,因此Session应该是最佳选择。一旦用户的会话结束,它就会消失。顺便说一句,如果您选择将其存储在服务器上,请使用SecureString类。

答案 3 :(得分:1)

正如约翰·麦金太尔所写,你应该使用综合安全和模仿。

如果由于某种原因您无法使用它并且您将提供自己的登录页面,请务必使用SSL来加密浏览器和服务器之间的流量。如果不使用SSL,使用ViewState方法也是完全不安全的,有很多工具可以非常容易地查看内容。从您枚举的方法中,最好的方法是使用会话状态。您可以卸载从Web服务器内存中保存会话状态,并保存that data in a database,以便您可以按照自己的方式保护。如果您不喜欢这些工作方式,您甚至可以编写自己的session state provider并应用您需要的安全性。

答案 4 :(得分:0)

在Viewstate中存储会增加您的曝光率,因为密码会一次又一次地在互联网上传播。如果加密足以应对这种风险,那取决于你。

使用Application或Session都会将密码保存在服务器中。如上所述,SecureString将使人们不会简单地读取内存中的密码。会话将扩展到更多用户,并且可能比应用程序更容易扩展到多个服务器。除非您确定永远不会使用超过1个Web服务器,否则我将不会使用Application,因为您可以自行同步所有服务器。

答案 5 :(得分:0)

永远不要存储密码!

而是存储密码的哈希值。请参阅:http://en.wikipedia.org/wiki/Crypt_(Unix)#Library_Function

我知道这不能回答这个问题,但是越多程序员忽视这个建议,犯罪分子就越容易窃取数据。不要让你的组织成为新闻报道。

答案 6 :(得分:0)

用户名/密码确实不应存储在任何地方。

存储实时数据库连接,最好是从Session对象中的池中存储。只要登录数据库,您只需要用户名/密码。

虽然另一个页面可以使用实时连接,但它不会像其他人那样通过存储用户名/密码来永久访问数据库。

相关问题