Home/ Questions/Q 6344831
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T20:42:59+00:00

I am looking for protocol/algorithm that will allow me to use a shared secret

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?

    • 0