Improve my Shared Secret Algorithm/Methodology & suggest a Encryption Protocol

I am looking for protocol/algorithm that will allow me to use a shared secret between my App & a HTML page.

The shared secret is designed to ensure only people who have the app can access the webpage.

My Problem: I do not know what algorithm(my methodology to validate a开发者_如何学运维 valid access to the HTML page) & what encryption protocol I should use for this.

People have suggested to me that I use HMAC SHAXXX or DES or AES, I am unsure which I should use - do you have any suggestions?

My algorithm is like so:

• I create a shared secret that the App & the HTML page know of(lets call it "MySecret"). To ensure that that shared secret is always unique I will add the current date & minute to the end of the secret then hash it using XXX algorithm/protocol(HMAC/AES/DES). So the unencrypted secret will be "MySecret08/17/2011-11-11" & lets say the hash of that is "xyz"
• I then add this hash to the url CGI: http://mysite.com/comp.py?sharedSecret=xyz
• The comp.py script then uses the same shared secret & date combination, hashes it, then checks that the resulting hash is the same as the CGI variable sharedSecret("xyz"). If it is then I know a valid user is accessing the webpage.

Can you think of a better methodology to ensure on valid people can access my webpage(the webpage allows the user to enter a competition)?

I think I am on the correct track using a shared secret but my methodology for validating the secret seems flawed especially if the hash algorithm doesn't produce the same result for the same in put all the time.

especially if the hash algorithm doesn't produce the same result for the same in put all the time.

Then the hash is broken. Why wouldn't it?

You want HMAC in the simple case. You are "signing" your request using the shared secret, and the signature is verified by the server. Note that the HMAC should include more data to prevent replay attacks - in fact it should include all query parameters (in a specified order), along with a serial number to prevent the replay of the same message by an eavesdropper. If all you are verifying is the shared secret, anyone overhearing the message can continue to use this shared secret until it expires. By including a serial number, or a short validity range, you can configure the server to flag that.

Note that this is still imperfect. TLS supports client and server side certificate support - why not use that?

The looks like it would work. Clock drift could be a problem, you may need to validate a range of, say, +/- 3 minutes if it fails for the exact time.

flawed especially if the hash algorithm doesn't produce the same result for the same input all the time

Well, that would be a broken hash algorithm then. A hash reliable produces the same output for the same input every time (and almost always a different output for a different input).

Try using some sort of network encryption. Your web server should be able to handle that type of authentication automatically. All that remains is for you to write it into your app (which you have to do anyway). Depending on your app platform, you may be able to do that automatically as well.

Google these: Kerberos, SPNEGO and HTTP 401 Authorization Required. You may be able to get away with simple hard-coded user name and password HTTP headers and run your connections over HTTPS. That way you have less custom code on your server and your server takes care of authenticating your requests for you. Not to mention you are taking advantage of some additional features of HTTP.