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

在我看来,这次会议的自然地点是会议。

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

但如果你要这么做 那个 数据也可以在视图状态中。

我不喜欢这些想法,但是 完全讨厌视图状态的想法 .

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

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

关于 Session 和 Application 我不认为 应用 方法是有意义的。数据是用户特定的,所以 会话 应该是去的路。一旦用户的会话关闭,它就会消失。顺便说一下,如果您选择将其存储在服务器上,请使用 SecureString 班级。

正如约翰麦金太尔所写,您应该为此使用集成的安全性和模拟。

如果由于某种原因您不能使用它,并且您将提供自己的登录页面,那么请使用SSL来加密浏览器和服务器之间的通信。使用viewstate方法也是完全不安全的。如果您不使用ssl,那么有一些工具可以很容易地查看内容。从枚举的方法中,最好的方法是使用会话状态。您可以从Web服务器内存中卸载保存会话状态并保存 that data in a database 你可以按照你想要的方式来保护自己。如果你不喜欢这些工作方式,你甚至可以自己写。 session state provider 在那里申请你需要的安全。

在viewstate中存储会增加您的曝光,因为密码会一次又一次地在互联网上飞来飞去。加密是否足够好来解决这个风险取决于您。

使用应用程序或会话都会在服务器中保留密码。如上所述,secureString将防止人们简单地从内存中读取密码。会话将扩展到更多的用户,可能更重要的是扩展到多个服务器,这比应用程序容易得多。除非您确定永远不会使用超过1个Web服务器,否则我不会使用应用程序,因为所有服务器的同步将由您决定。

不要存储密码!

而是存储密码的散列值。见: http://en.wikipedia.org/wiki/Crypt_(Unix)#Library_Function .

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

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

您可以存储一个实时数据库连接,最好是从会话对象中的池进行存储。只要登录到数据库,就只需要用户名/密码。

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