【发布时间】: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);
}
概念:
- “session_hash”旨在防止同一个 cookie 在多台机器上使用,并强制规定一个时间段,之后它就会失效。
- “session_hash”和“captcha_hash”都有自己的加密盐密钥。
- 这些 BASE64_8192BIT_SECRET_A 和 _B salt 密钥是存储在服务器上的 RSA 私钥的一部分。
- “captcha_hash”用秘密和“session_hash”加盐。
- 在使用客户端提供的数据的地方添加了分隔符,以避免拼接攻击。
- “captcha_hash”和“session_hash”都存储在客户端cookie中。
编辑:re:Kobi 感谢您的反馈!
(我会在 cmets 中回复,但它似乎不接受问题中的格式?)
每次他们访问登录页面时,验证码都会被替换;但是,这确实假设他们不会在不重新加载登录表单页面的情况下简单地重新提交。基于会话的实现使用过期时间来避免这个问题。我们也可以向登录页面添加一个随机数,但我们也需要服务器端会话存储。
根据 Kobi 的建议,哈希数据中现在包含过期时间范围,但共识是将其添加到 session_hash 中,因为会话超时是很直观的。
对一些数据进行散列并在该数据中包含另一个散列的想法对我来说似乎是可疑的。真的有什么好处吗,或者我们最好使用包含所有相关数据(时间、IP、用户代理、验证码值和密钥)的单个哈希。在这个实现中,我们基本上是在告诉用户散列明文的一部分。
问题:
- 是否有明显的不足?
- 是否有任何细微的缺陷?
- 有更稳健的方法吗?
- 用另一个哈希对哈希加盐有什么帮助吗?
- 是否有更简单且同样稳健的方法?
新问题:
我个人认为我们最好将其保留为服务器端会话;谁能指出我有任何论文或文章证明或反驳仅将所有验证数据发送到客户端的固有风险?
【问题讨论】:
标签: security authentication cryptography captcha