1. Software Standards Specification
  2. Software Requirements Definition
  3. Software Best Practices
  4. Input Validation
  5. Output Validation
  6. Cookie Requirements
  7. Access Failure Error Checking
  8. Buffer Overflow
  9. Code Structure
  10. Software Functions
  11. Software Modules
  12. Requirements for Variables
  13. Software Code Comment Requirements
  14. Quality Code Requirements
  15. Software Code Review
  16. Software Code Testing Requirements
  17. Software Change Control

    Security Best Practices

  18. Secure Functional Requirements
  19. Account Creation
  20. Change Password
  21. Forgot Password
  22. Personal Question
  23. Contact Webmaster
  24. CAPTCHA Tests
  25. Answer Verification

Answer Verification

This page is provided for consideration and reference regarding shared secret verification.

The answer verification method described here is a method that can be used for a server to verify a known answer (shared secret) between itself and a client without a third party being able to intercept it. This method should provide a reasonable level of security without using encryption such as HTTPS. The reason for this is that the actual answer is never sent.

MD5 salted hash technique

  1. The server sends a large random number to the client when the logon page is requested.
  2. The user enters their password.
  3. Client side Javascript creates a SHA1 hash of the entered password.
  4. Client side Javascript appends the large random number to the SHA1 hash of the password and creates a hash from the result.
  5. The large random number and hash are transmitted to the server.
  6. The server reads the hash of the user password from the database and appends the large random number to it.
  7. The server creates a hash from the result in the above step and compares it to the received hash from the client.
  8. If the resulting hash matches the transmitted hash, the password is the same and logon is successful.

This has the following strengths:

  • The password is never transmitted.
  • The password hash is never transmitted so it is also protected. In fact the attacker could use the password hash to login if they could obtain it.
  • Even though a third party may know the large random number, they cannot re-create the password hash without attempting a brute force attach against many of the possible password hash numbers. Therefore the password hash must be very long and the hash calculation must be CPU cycle intensive enough to make many calculations difficult but not difficult for one.

If the entire session were encrypted, the exchange would be more secure because an attacker would need to decrypt the large random number, and the combined hash value that was sent to the server before they could perform a brute force attack. If a dictionary attack is used, the attacker would need to do more math to convert text passwords to their hash value.

CAPTCHA answer technique 1

This technique is designed for the client to be able to submit a test answer to the server and the server be able to tell by what is submitted including hidden characters, whether the answer is correct. This technique will be susceptible to a replay attack unless the large random number is stored in a database table.

  1. The server chooses a large random number
  2. The server chooses a question for the user and knows the correct answer.
  3. The server calculates the hash of ( answer + large random number + IP address + (time + 4096)/8192 )
  4. The server encrypts the large random number (may use a public key so it can only be encrypted privately)
  5. The server sends the hash and encrypted large random number to the client with the question.
  6. The client sends the answer back with the encrypted large random number and the hash generated in step 3.
  7. The server decrypts the large random number.
  8. The server calculates the hash of ( answer received + large random number + IP address + (time + 4096)/8192 )

If the calculated hash is the same as the received hash, the answer is accepted. The use of the IP address prevents replay from another IP address. The use of the fractionalized time limits the replay attack ability to aboout 1 hour and still gives the user that amount of time to fill out the form.