隐藏源中保存的密码

时间:2011-09-27 08:17:50

标签: html

我有一个登录表单和一个记住密码的选项。密码在用户计算机上的cookie中加密。目前它被解密并放在密码字段中。这不是那个闪存,因为您只是查看源以查看用户密码。

从源代码获取密码的最佳方法是什么?

2 个答案:

答案 0 :(得分:6)

不要那样做。任何登录表单的安全实施都将使密码可读。

您有两种选择:

  • 使用cookie自动登录用户。非常方便,这是大多数人想要的。
  • 让用户在文本字段中保存密码。每个浏览器都可以以一种或多或少的安全方式执行此操作并跳过cookie。

让我再说一遍:在代码中显示明文密码是安全风险。但是,您知道用户的密码或能够重新创建它(对称加密而不是散列 - 您应该使用什么)是一件复杂的事情,因为我不信任每个清楚地知道我的密码的网站或者将它存储在任何地方。

因此,您可以在注册时从用户那里获取密码,将其哈希并将其存储在数据库中或者您喜欢的任何地方。然后,让cookie记住用户(意味着身份,而不是用于验证身份的凭据)。

答案 1 :(得分:0)

  1. 没有记住密码的选项。浏览器可以安全地自行完成。相反,使用一个选项来保持用户登录。在这种情况下,您设置一个cookie来维护用户在服务器会话之间的会话,该会话基于会话令牌(通常包括加密的用户名),而不是密码。

  2. 您永远不能解密用户的密码以读取纯文本。使用散列而不是加密。您可以使用SHA1等算法在客户端散列密码,而不是将纯文本发送到服务器。许多应用程序跳过了第一步,但最好永远不要以明文形式传输密码。然后,在服务器端,使用动态盐作为密钥,使用类似HMAC-SHA1的算法再次散列“密码哈希”。您应该为每个用户的密码使用不同的随机盐。这样,即使两个用户拥有相同的密码,salt也可以确保每个密码的保存方式不同。您为每个用户在数据库中存储密码和salt,因此在与每次登录时的用户密码进行比较时可以再次使用它。

  3. 无论您是存储包含用户名的会话令牌,还是用户的密码(应该只是密码的哈希值,并且仍然是不可取的),您都应该对cookie进行加密(如您所述)您已经拥有)并在服务器端解密cookie,而不是客户端。如果您解密客户端,那么您已经放弃了算法和密钥,这将使加密成为毫无意义的练习。此外,如果您解密服务器端,然后将密码发回管道以预加载您的登录表单,则在传输到浏览器期间会显示用户的密码,并在从浏览器重新提交登录表单时再次这样做。

  4. 当用户在返回您的站点后发出第一个请求时,您将在HTTP标头中获取cookie,因此如果您使用会话令牌而不是密码,您可以立即解密cookie,验证会话令牌仍然有效,将用户登录,并将用户带到内容页面。这是允许持久会话cookie的每个站点的功能。

  5. 如果您将密码存储在cookie中,我假设您还存储用户名,或者将用户名从服务器发送到浏览器。然后,当您以明文形式在登录表单中预加载用户名和密码时,您可以在您的网站和其他可能的网站上提供小偷凭据。您泄漏有关用户的信息。如果您在cookie中存储会话令牌(其中包含用户名和到期时间戳而不是密码),并且只解密服务器上的令牌,那么您没有泄露任何用户信息。此外,您可以使用HttpOnly cookie,因为您的客户端脚本不需要读取cookie。

  6. 从您的角度来看,这两种方法对您的用户完全基本相同,但是仅包含用户名的加密会话令牌对用户造成的风险远远低于存储(加密或未加密)和/或解密的密码预加载您的登录表单。

    要创建会话令牌,请创建Cookie并添加用户名以及您选择的发布日期和/或到期日期。如果设置了发布日期,则可以始终根据服务器上的当前过期策略计算过期日期。如果您的政策发生变化,那么它也始终适用于旧令牌。如果您只设置过期日期并验证当前日期是否小于过期日期,那么您正在使用在存储cookie时考虑的任何过期持续时间策略。会话令牌通常包括以下内容:

    • 用户名 - 因此它特定于您可以验证的用户帐户
    • 发行日期 - 当前时间戳
    • 到期日期 - 当前时间戳+到期窗口
    • 持久性 - 指示cookie应在当前服务器会话结束时保持持久性还是过期的属性
    • 任何自定义数据(无密码)