可以在web.config中
<system.web>
<identity impersonate="true"
userName="administrator"
password="你的密码"/>
来解决一些需要特别权限的操作，比如增加一个组，增加一个Windows用户待，
但这样将明码写在Web.config中，不是令人担扰，
如果不写这个而用administrator作业匿名访问用户来访问站点，会不会存在安全性
问题.跟前一种方式有什么样的区别,请指教，这不是开玩笑的。
(记得以前在用ASP时有一个GetObject(...)也是需要administrator去执行才有权限,那时我是用
administrator作为匿名用户来开执行)第二个问题是:authenticated users组到底是用来执行什么的，掌握了哪些权限？因为在
Temporary ASP.NET Files中将其删除就无法编译ASP.net文件.这两个问题我在CSDN中发了很多次了，就是没人回答,望高人指点
<system.web>
<identity impersonate="true"
userName="administrator"
password="你的密码"/>
来解决一些需要特别权限的操作，比如增加一个组，增加一个Windows用户待，
但这样将明码写在Web.config中，不是令人担扰，
如果不写这个而用administrator作业匿名访问用户来访问站点，会不会存在安全性
问题.跟前一种方式有什么样的区别,请指教，这不是开玩笑的。
(记得以前在用ASP时有一个GetObject(...)也是需要administrator去执行才有权限,那时我是用
administrator作为匿名用户来开执行)第二个问题是:authenticated users组到底是用来执行什么的，掌握了哪些权限？因为在
Temporary ASP.NET Files中将其删除就无法编译ASP.net文件.这两个问题我在CSDN中发了很多次了，就是没人回答,望高人指点
基于窗体的身份验证
基于窗体的身份验证是 ASP.NET 身份验证服务，它使应用程序能够提供它们自己的登录用户界面以及进行它们自己的凭据验证。ASP.NET 验证用户的身份，将未授权的用户重定向到登录页并执行所有必要的 Cookie 管理。这种身份验证是许多 Web 站点使用的流行方法。应用程序必须被配置成使用基于窗体的身份验证，将 <authentication> 设置为 Forms 并且拒绝匿名用户访问。下面的示例说明如何在所需应用程序的 Web.config 文件中完成此配置：<configuration>
<system.web>
<authentication mode="Forms"/>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>管理员使用基于窗体的身份验证，配置要使用的 Cookie 的名称、保护类型、用于登录页的 URL、Cookie 有效的时间长度以及用于已发布的 Cookie 的路径。下表显示了 <Forms> 元素（它是下面的示例中显示的 <authentication> 元素的子元素）的有效属性：<authentication mode="Forms">
<forms name=".ASPXCOOKIEDEMO" loginUrl="login.aspx" protection="All" timeout="30" path="/">
<!-- protection="[All|None|Encryption|Validation]" -->
</forms>
</authentication>属性 说明
loginUrl 指定一个 URL，未授权用户的请求将被重定向到该 URL。该 URL 可以在同一台计算机上或在远程计算机上。如果它在远程计算机上，两台计算机需要对 decryptionkey 属性使用相同的值。
name 用于身份验证目的的 HTTP Cookie 的名称。注意：如果不止一个应用程序要在一台计算机上使用基于窗体的身份验证服务，则每个应用程序应该配置唯一的 Cookie 值。为了避免在 URL 中导致依赖项，ASP.NET 在设置身份验证 Cookie 时将“/”用作 Path 值，这使 Cookie 被发送回站点上的每个应用程序。
timeout 以整数分钟为单位的时间量，超过此时间量，Cookie 将过期。默认值是 30。超时属性是一个变化值，从收到最后一个请求的时间开始计算，它过期 n 分钟。为了避免对性能产生负面影响，也为了避免那些打开了 Cookie 警告的应用程序产生多个浏览器警告，Cookie 在超时时间过半时更新。（这意味着在某些情况下会丢失可能的精度。）
path 用于已发出 Cookie 的路径。默认值为“/”以避免因路径中有不匹配的大小而带来的困难，因为在返回 Cookie 时，浏览器严格区分大小写。共享服务器环境中的应用程序应该使用此指令维持专用 Cookie。（另一种方法是，它们可以使用 API 在运行时指定路径以发出 Cookie。）
protection 用于保护 Cookie 数据的方法。有效值如下所示：
All：同时使用数据验证和加密来保护 Cookie。配置的数据验证算法基于 元素。如果三重 DES 可用并且密钥足够长（48 位），则使用三重 DES 进行加密。All 是默认（和建议）值。
None：用于仅将 Cookie 用于个性化并且安全要求不高的站点。加密和验证都可以被禁用。尽管以此方式使用 Cookie 需谨慎，但对于使用 .NET Framework 实现个性化的任何方法，此设置提供了最佳性能。
Encryption：使用 TripleDES 或 DES 加密 Cookie，但不对 Cookie 进行数据验证。这类 Cookie 容易受到精心选择的纯文本的攻击。
Validation：不加密 Cookie 的内容，但验证 Cookie 数据在传输过程中是否未被更改。若要创建 Cookie，验证密钥在缓冲区中与 Cookie 数据连接，并且计算出 MAC 并将其追加到输出的 Cookie。
配置了应用程序后，需要提供一个登录页。下面的示例显示了一个简单的登录页。示例在运行时要求 Default.aspx 页。未授权的请求被重定向到登录页 (Login.aspx)，此页显示一个简单的窗体，提示用户输入电子邮件地址和密码。验证了凭据后，应用程序调用下列内容：FormsAuthentication.RedirectFromLoginPage(UserEmail.Value, PersistCookie.Checked);这将用户重定向回当初请求的 URL。不想执行重定向的应用程序既可以调用 FormsAuthentication.GetAuthCookie 来检索 Cookie 值，也可以调用 FormsAuthentication.SetAuthCookie 将正确加密的 Cookie 附加到输出的响应中。对于提供嵌入在包含页中的登录用户界面的应用程序，或者想要更多地控制用户被重定向到的位置的应用程序而言，这些方法很有用。身份验证 Cookie 既可以临时又可以永久（“持久”）。临时 Cookie 只在当前浏览器会话期间保持。当浏览器关闭时，临时 Cookie 随即丢失。永久 Cookie 则被浏览器保存，并在浏览器会话间回发，直到被用户显式删除。
窗体身份验证使用的身份验证 Cookie 由 System.Web.Security.FormsAuthenticationTicket 类的线性版本组成。信息包括用户名（但没有密码）、使用的窗体身份验证版本、发出 Cookie 的日期以及可选的应用程序特定数据的字段。通过使用 FormsAuthentication.SignOut 方法，应用程序代码可以撤消或移除身份验证 Cookie。这将移除身份验证 Cookie，不论它是临时的还是永久的。还可以使用配置为基于窗体的身份验证服务提供有效凭据的列表，如下例所示：<authentication>
<credentials passwordFormat="SHA1" >
<user name="Mary" password="94F85995C7492EEC546C321821AA4BECA9A3E2B1"/>
<user name="John" password="5753A498F025464D72E088A9D5D6E872592D5F91"/>
</credentials>
</authentication>应用程序然后可以调用 FormsAuthentication.Authenticate 并提供用户名和密码，ASP.NET 将验证凭据。根据 passwordFormat 属性的下列值，凭据可以存储在明文中，或者存储为 SHA1 或 MD5.哈希类型 说明
Clear 密码存储在明文中
SHA1 密码存储为 SHA1 摘要
MD5 密码存储为 MD5 摘要
我始终对IIS有怀疑态度，但我要用.net没办法.
盡管很多人都說web.config相對較安全.但也不是絕對安全.
有沒有可以加密的方法,直接把密碼寫在上面心里總是有點擔心.