title: Cryptographic security of Captcha hash cookie
body: <p>My company's CRM system utilizes a captcha system at each login and in order to utilize certain administrative functions. The original implementation stored the current captcha value for in a server-side session variable. </p>
  
  <p>We're now required to redevelop this to store all necessary captcha verification information in a hashed client-side cookie. This is due to a parent IT policy which is intended to reduce overhead by disallowing use of sessions for users who are not already authenticated to the application. Thus, the authentication process itself is disallowed from using server-side storage or sessions. </p>
  
  <p>The design was a bit of a group effort, and I have my doubts as to its overall efficacy. My question is, can anyone see any obvious security issues with the implementation shown below, and is it overkill or insufficient in any way?</p>
  
  <p>EDIT: Further discussion has led to an updated implementation, so I've replaced the original code with the new version and edited the description to talk to this revision.</p>
  
  <p>(The code below is a kind of pseudo-code; the original uses some idiosyncratic legacy libraries and structure which make it difficult to read. Hopefully this style is easy enough to understand.)</p>
  
  <pre><code>// 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);
  }
  </code></pre>
  
  <p>Concept:</p>
  
  <ol>
  <li>The "session_hash" is intended to prevent the same cookie from being used on multiple machines, and enforces a time period after which it becomes invalid.</li>
  <li>Both the "session_hash" and "captcha_hash" have their own secret salt keys.</li>
  <li>These BASE64_8192BIT_SECRET_A and _B salt keys are portions of an RSA private key stored on the server.</li>
  <li>The "captcha_hash" is salted with both the secret and the "session_hash".</li>
  <li>Delimiters are added where client-provided data is used, to avoid splicing attacks.</li>
  <li>The "captcha_hash" and "session_hash" are both stored in the client-side cookie.</li>
  </ol>
  
  <p>EDIT: re:Kobi Thanks for the feedback!</p>
  
  <p>(I would reply in comments, but it doesn't seem to accept the formatting that works in questions?)</p>
  
  <p>Each time they access the login page, the captcha is replaced; This does however assume that they don't simply resubmit without reloading the login form page. The session-based implementation uses expiration times to avoid this problem.  We could also add a nonce to the login page, but we would need server-side session storage for that as well.</p>
  
  <p>Per Kobi's suggestion, an expiration timeframe is now included in the hashed data, but consensus is to add it to the session_hash instead, since it's intuitive for a session to have a timeout. </p>
  
  <p>This idea of hashing some data and including another hash in that data seems suspect to me. Is there really any benefit, or are we better off with a single hash containing all of the relevant data (time, IP, User-agent, Captcha value, and secret key). In this implementation we are basically telling the user part of the hashed plaintext.</p>
  
  <p>Questions:</p>
  
  <ol>
  <li>Are there any obvious deficiencies?</li>
  <li>Are there any subtle deficiencies?</li>
  <li>Is there a more robust approach?</li>
  <li>Is salting the hash with another hash helping anything?</li>
  <li>Is there a simpler and equally robust approach?</li>
  </ol>
  
  <p>New question:</p>
  
  <p>I personally think that we're better off leaving it as a server-side session; can anybody point me to any papers or articles proving or disproving the inherent risk of sending all verification data to the client side only?</p>