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
The server sends a large random number to the client when the logon page is requested.
The user enters their password.
The large random number and hash are transmitted to the server.
The server reads the hash of the user password from the database and appends the large random number to it.
The server creates a hash from the result in the above step and compares it to the received hash from the client.
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.
The server chooses a large random number
The server chooses a question for the user and knows the correct answer.
The server calculates the hash of ( answer + large random number + IP address + (time + 4096)/8192 )
The server encrypts the large random number (may use a public key so it can only be encrypted privately)
The server sends the hash and encrypted large random number to the client with the question.
The client sends the answer back with the encrypted large random number and the hash generated in step 3.
The server decrypts the large random number.
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.