【问题标题】:'Remember-me' authentication feature, does it always mean 'Unsecure' Website?“记住我”身份验证功能,是否总是意味着“不安全”网站?
【发布时间】:2011-01-23 04:53:35
【问题描述】:

我正在考虑在我的 web 应用上实现经典的'remember-me' 复选框,以允许在经过身份验证的用户返回访问我的网站后被“记住”。

GmailFacebook 和其他人都有这种功能,但我不太确定它有多安全。

Spring Security 这样的Java 框架使用“基于哈希的令牌方法”。生成的令牌(使用用户名、密码、过期时间和私有密钥)存储在客户端的 Cookie 'token=567whatever567' 中。然后,该令牌会在用户下次回来时重新对用户进行身份验证。

我担心即使登录过程发生在 https 连接下,在每个后续的 http 请求中,cookie 都会在网络上以未加密的方式发送。

基本上每个人都可以读取令牌并重用它来进行身份验证。

我正在尝试了解 Gmail 或 Facebook 是如何实现此功能的。我可以在 FB 中看到一些 Cookie,例如 'presence=DJ267619445G09H0L15228675.....',其他在 Gmail 中。
我不太确定他们是否使用其他技巧来防止有人试图冒充其他用户。

我会尝试使用cURL 之类的东西来冒充自己,看看他们是否只使用特定的令牌来记住用户。
如果是的话,在我看来这是一个很大的安全问题。也许不是 facebook(我不在乎),但如果您不设置“Use always https”,则使用 Gmail,将使用 http 连接,它将通过互联网发送您未加密的令牌。
你怎么看?

我还注意到 Facebook 用户名/密码字段在 http(不是 https)下公开。在这方面,我也想知道:是否所有网站都通过 http 不安全“本质上”公开用户名/密码字段。一旦通过 http 发送请求,就没有“重定向到 https”可以解决“全世界可见的凭证”问题。

谢谢

编辑
我的担心是有根据的http://codebutler.com/
感谢Firesheep 创作者指出问题!!!

【问题讨论】:

    标签: security web-applications cookies https remember-me


    【解决方案1】:

    实现记住我不是什么问题。您需要做的是让会话长时间保持活动状态(并将 cookie 设置为持续很长时间)。甚至Gmail也会在一段时间后将您注销(我认为是两周或一个月)。但是,您需要意识到保持相同会话打开的时间更长会增加劫持它的可能性。作为对策,您需要增加会话标识符的强度。会话标识符是 cookie 中的标识符(或在某些软件中常见的 URI 中,如“file.php?PHPSESSID=1234...”)。

    关键是保持强大的会话标识符。例如,在 Gmail 中,您有一个 cookie GX,其值类似于

    DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ
    

    Session Hijacking 几乎不可能的原因是,因为会话标识符非常强大,并且因为该站点在任何地方都使用 HTTPS。没有人可以猜测或以其他方式获取您的会话标识符(因此无法劫持您的会话)。快速浏览一下,上面的会话标识符似乎有大约 1250 位的强度,1*10^376 种不同的可能性。没有人能猜到。

    很明显,总会有潜在的方法来劫持会话。例如,XSS 漏洞为获取您的 cookie 和会话标识符打开了大门,但这绝不是您的会话错误,与“记住我”无关。

    我担心即使登录过程发生在 https 连接下,在每个后续的 http 请求中,cookie 都会在网络上以未加密的方式发送。

    如果您在 HTTPS 中将 cookie 安全标志设置为 true,则在通过 HTTP 访问站点时将永远不会发送 cookie。对于仅使用 HTTPS 的网站,这是必须要做的。

    一般来说,人们似乎只对登录页面使用HTTPS,这是错误的。如果有人真的关心,他应该在整个页面上使用 HTTPS。否则,不可能阻止所有 Session Hijacking 尝试。

    为什么很多人仍然只在登录部分使用 HTTPS?可能是因为他们没有意识到其中的利害关系,或者因为 CPU 太重而无法在任何地方使用 HTTPS。但是,使用 HTTPS 登录仍然比在任何地方都不使用要好 - 因为它会加密凭据(因此以后只能窃取会话标识符,而不是登录期间的实际凭据)。

    也许不是 facebook(我不在乎),但如果您未设置“始终使用 https”,则使用 Gmail,将使用 http 连接,它将通过互联网发送您未加密的令牌。 你怎么看?

    如果可能,我认为在所有情况下该值都应默认为 HTTPS。为什么不使用 HTTPS 的唯一真正原因是钱(=性能/硬件)。

    【讨论】:

    • 任何以纯文本形式发送的标识符,无论多长时间,如果我可以通过中间人使用恶意路由器窃取它并在我自己的请求中使用它,那么它都是不安全的。被盗令牌无需解密即可用于重放攻击。这可能会使猜测身份验证令牌变得困难/不可能,但这不是所要求的。
    • 正如我所说,如果不使用 HTTPS,就不可能阻止所有 Session Hijacking 尝试。
    • 所以,我现在在 SO 中登录。如果我单击“提问”,我将通过普通 Http 发布我的新问题。基本上每个人都可以拦截请求的 Cookie 并重用它们以“al nik”的身份发送新问题......这是正确的吗?
    • 有人甚至可以更改我的个人资料(因为到处都使用 http)。 SO似乎没有使用任何“安全cookie”。它是否正确?防止任何攻击的唯一方法是设置一个仅通过 https 传输的安全 Cookie,并使用 https 进行只有经过身份验证的用户可见的所有操作。
    • 这可能会降低网站速度,但这是防止 Cookie 被盗的唯一方法
    【解决方案2】:

    通常称为重放攻击。攻击者使用从您那里窃取的相同凭据(例如 cookie)重放请求,并且能够冒充您。 XSS 攻击只是其中的一种变体,但可以预防(例如使用 HTTPOnly)。

    减轻大多数重放攻击的唯一方法是无处不在的 https。这应该可以避开大多数窥探的眼睛。

    还有lots of prevention techniques

    还有一些硬件设备比你在软件中破解的工作做得更好,在这个过程中会减慢你的服务器,你可能会弄错。专用硬件可以更好地实时跟踪请求并确定许多不同的 IP 同时使用相同的令牌,并且比单个人工操作员应该能够请求的速度更快。

    在 ASP.NET 2.0+ 中,当使用表单身份验证时,您可以指定 requireSSL='true' 以指示浏览器仅应在建立 https 连接时发送身份验证 cookie。有关保护表单身份验证的更多信息,请参阅this msdn article


    不允许remember me 的唯一原因是您是银行或类似应用程序。如果不是,请遵循一些简单的规则:

    1. 如果您有remember me,请将cookie 设置为最多30 天后到期,并且不要滑动值。强制用户每月登录一次还不错。
    2. 任何敏感操作需要密码。在更新帐单、信用卡或帐户详细信息时总是重新请求用户密码。最可能的滥用形式通常是通过该人使用的同一台计算机,但它也确保即使是被盗的身份验证 cookie 本身也不会造成太大的伤害。你可以看到我的余额,但你不能转移任何东西。

    【讨论】:

      【解决方案3】:

      同意上面制作的大多数cmets。如果您担心安全问题,您应该 -

      a) 始终使用 https。甚至 gmail 最近也默认使用 https - 请参阅 http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html

      b) 在会话 cookie 中设置安全标志,以防止浏览器通过 http 连接发送它。

      c) 修复应用程序中的 XSS。如果您有 xss 问题,那么您的“记住我”的实现总是不安全的。请参阅 OWASP XSS 预防备忘单。

      在会话标识符中包含 IP 地址不会有帮助。这样做会使“记住我的功能”变得毫无用处,并且不会增加太多安全性。我确定 google 不会将 IP 地址放在其会话标识符中。

      【讨论】:

        【解决方案4】:

        使网站完全安全的唯一方法是在任何地方启用 https。你是对的,cookies 可以被嗅探,然后被用来模仿。

        【讨论】:

          【解决方案5】:

          preventing session hijacking 有几种方法,例如存储打开会话的客户端的 IP 地址。即使没有自动登录功能,其他数据也必须存储在服务器端以验证会话。最好使用nonce 作为令牌(或至少基于非机密数据)而不是散列的用户名和密码,因为可以想象攻击者可以发起攻击以查找给定散列值的身份验证信息。

          如果您查看 Facebook、Gmail 和可能其他网站的登录表单的来源,登录表单操作使用 HTTPS,然后在登录成功后重定向到非安全页面。

          【讨论】:

          • IP 只是一种略微成功的解决方案,它忽略了使用分布式代理的大型 ISP 或公司。
          【解决方案6】:

          1/ 当用户选中“记住我”时:您存储有关他的计算机的所有信息的哈希值:IP、浏览器、操作系统、语言等...并且您将此哈希值与他的 ID 一起写入他的 cookie 2/ 当用户回来时,你计算他的新哈希。您将此值与接收到的 cookie 中的值以及数据库中的值(对于给定的 id)进行比较。如果他们都是平等的,你可以验证用户。

          清楚吗?

          如果你有 XSS 攻击,Https 什么都做不了(窃取 cookie 的最佳方法)

          【讨论】:

          • 有人仍然可以知道操作系统、语言等等......并且令牌仍然通过网络传输而没有加密,因此每个人都可以看到它。我认为,将 IP 作为生成令牌的一部分也不太适合我们记住我的概念。如果我在家登录,当我从办公室连接并且 IP 不同时,我仍然希望能够被记住。
          • @al 令牌是通过网络传输的,没有被传输,但它是一个哈希,所以即使你看到它,你也无法知道我们是如何创建它的。您可以为同一个用户保存多个哈希。
          猜你喜欢
          • 1970-01-01
          • 2012-02-13
          • 2011-10-15
          • 2020-01-19
          • 2018-01-04
          • 1970-01-01
          • 1970-01-01
          • 2017-04-27
          • 1970-01-01
          相关资源
          最近更新 更多