【问题标题】:Cryptographic security of Captcha hash cookieCaptcha 哈希 cookie 的加密安全性
【发布时间】:2009-10-26 18:37:26
【问题描述】:

我公司的 CRM 系统在每次登录时都使用验证码系统,以便利用某些管理功能。原始实现将当前验证码值存储在服务器端会话变量中。

我们现在需要重新开发它以将所有必要的验证码验证信息存储在散列的客户端 cookie 中。这是由于父 IT 策略旨在通过禁止对尚未通过应用程序进行身份验证的用户使用会话来减少开销。因此,不允许身份验证过程本身使用服务器端存储或会话。

这个设计有点集体努力,我对它的整体效果表示怀疑。我的问题是,任何人都可以看到下面显示的实现有任何明显的安全问题吗?它是矫枉过正还是不足?

编辑:进一步的讨论导致了更新的实现,因此我用新版本替换了原始代码并编辑了描述以与此修订版交谈。

(下面的代码是一种伪代码;原文使用了一些特殊的遗留库和结构,使其难以阅读。希望这种风格足够容易理解。)

// Generate a "session" cookie unique to a particular machine and timeframe
String generateSessionHash(timestamp) {
    return sha256( "" 
        + (int)(timestamp / CAPTCHA_VALIDITY_SECONDS)
        + "|" + request.getRemoteAddr() 
        + "|" + request.getUserAgent() 
        + "|" + BASE64_8192BIT_SECRET_A
    );
}

// Generate a hash of the captcha, salted with secret key and session id
String generateCaptchaHash(captchaValue, session_hash) {
    return sha256( ""
        + captchaValue
        + "|" + BASE64_8192BIT_SECRET_B
        + "|" + session_hash
    );
}

// Set cookie with hash matching the provided captcha image
void setCaptchaCookie(CaptchaGenerator captcha) {
    String session_hash = generateSessionHash(time());
    String captcha_hash = generateCaptchaHash(captcha.getValue(), session_hash);
    response.setCookie(CAPTCHA_COOKIE, captcha_hash + session_hash);
}

// Return true if user's input matches the cookie captcha hash
boolean isCaptchaValid(userInputValue) {
    String cookie = request.getCookie(CAPTCHA_COOKIE);
    String cookie_captcha_hash = substring(cookie, 0, 64);
    String cookie_session_hash = substring(cookie, 64, 64);
    String session_hash = generateSessionHash(time());
    if (!session_hash.equals(cookie_session_hash)) {
        session_hash = generateSessionHash(time() - CAPTCHA_VALIDITY_SECONDS);
    }
    String captcha_hash = generateCaptchaHash(userInputValue, session_hash);
    return captcha_hash.equals(cookie_captcha_hash);
}

概念:

  1. “session_hash”旨在防止同一个 cookie 在多台机器上使用,并强制规定一个时间段,之后它就会失效。
  2. “session_hash”和“captcha_hash”都有自己的加密盐密钥。
  3. 这些 BASE64_8192BIT_SECRET_A 和 _B salt 密钥是存储在服务器上的 RSA 私钥的一部分。
  4. “captcha_hash”用秘密和“session_hash”加盐。
  5. 在使用客户端提供的数据的地方添加了分隔符,以避免拼接攻击。
  6. “captcha_hash”和“session_hash”都存储在客户端cookie中。

编辑:re:Kobi 感谢您的反馈!

(我会在 cmets 中回复,但它似乎不接受问题中的格式?)

每次他们访问登录页面时,验证码都会被替换;但是,这确实假设他们不会在不重新加载登录表单页面的情况下简单地重新提交。基于会话的实现使用过期时间来避免这个问题。我们也可以向登录页面添加一个随机数,但我们也需要服务器端会话存储。

根据 Kobi 的建议,哈希数据中现在包含过期时间范围,但共识是将其添加到 session_hash 中,因为会话超时是很直观的。

对一些数据进行散列并在该数据中包含另一个散列的想法对我来说似乎是可疑的。真的有什么好处吗,或者我们最好使用包含所有相关数据(时间、IP、用户代理、验证码值和密钥)的单个哈希。在这个实现中,我们基本上是在告诉用户散列明文的一部分。

问题:

  1. 是否有明显的不足?
  2. 是否有任何细微的缺陷?
  3. 有更稳健的方法吗?
  4. 用另一个哈希对哈希加盐有什么帮助吗?
  5. 是否有更简单且同样稳健的方法?

新问题:

我个人认为我们最好将其保留为服务器端会话;谁能指出我有任何论文或文章证明或反驳仅将所有验证数据发送到客户端的固有风险?

【问题讨论】:

    标签: security authentication cryptography captcha


    【解决方案1】:

    假设除此处所述之外没有其他安全措施:
    似乎攻击者可以解决验证码一次,并保存 cookie。
    然后她有她的常量session_hashcaptcha_hash。没有什么能阻止她提交具有相同散列数据的相同 cookie - 可能会破坏您的系统。
    这可以通过使用time 作为captcha_hash 的一部分来避免(您需要将其四舍五入到一个偶数时间,可能是几分钟 - 并检查两个选项 - 当前时间和上一个时间)

    为了验证,你说:

    “session_hash”旨在防止同一个cookie在多台机器上使用。

    这是真的吗?
    isCaptchaValid 上,您正在执行String session_hash = substring(cookie, 64, 64); - 也就是说:您依赖于cookie 中的数据。你怎么知道它不是从另一台计算机复制的? - 您不会再次散列客户端数据以确认它(事实上,您那里有一个随机数,所以它可能是不可能的)。你怎么知道它是新的请求,没有被使用?

    我知道每次登录都会替换验证码,但是你怎么知道什么时候发出请求呢? 您没有在 isCaptchaValid 上检查新验证码 - 您的代码仍将验证请求,即使它与显示的验证码不匹配
    考虑以下场景(可以自动化):

    1. 前夕打开登录页面。
    2. 获取新的 cookie 和新的验证码。
    3. 用她的旧 cookie 和旧 cptcha 的散列数据替换它。
    4. 提交旧 cookie,并使用旧验证码字词 userInputValue
    5. 使用此输入,isCaptchaValid 验证请求 - captcha_hashsession_hashuserInputValueBASE64_8192BIT_SECRET 都与第一个请求相同。

    顺便说一句,在大多数系统中,无论如何您都需要一个 nonce,以避免 XSS,并且拥有一个也可以解决您的问题。

    【讨论】:

    • 你很有帮助。但是,在这种情况下,我们不是更担心马洛里而不是夏娃吗?
    • 太糟糕了,我不能在编辑后再次投票给相同的答案。
    • 确实如此。当我研究我们一直使用 Eve 时,我会注意 en.wikipedia.org/wiki/Alice_and_Bob
    猜你喜欢
    • 1970-01-01
    • 2018-11-04
    • 2016-08-03
    • 1970-01-01
    • 1970-01-01
    • 2017-06-05
    • 2012-01-25
    • 2011-12-17
    • 2012-07-09
    相关资源
    最近更新 更多