If we want to allow sensitive data between a web server and specific client only, is there anything more that can be done besides the following?

Note that this is potentially a duplicate of Authenticating client without hardcoding key? but the focus here is more on a good solution within this limitation (that there is no absolutely definitive solution to authenticate the client)

1) All traffic flows over SSL

2) Client has AES-256 key hardcoded yet obfuscated

3) Server has same AES-256 key

4) Client makes request for new "session key"

5) Server generates random session key and encrypts it with shared AES-key

6) Client decrypts, and all further exchange happens over this "session key" (which is also aes-256)

  • within what limitation? are the 6 steps the limitation or the thing you want to improve?
    – schroeder
    Mar 29, 2015 at 6:13
  • I'm also confused about why you are encrypting the data again within an SSL stream.
    – schroeder
    Mar 29, 2015 at 6:17
  • 1
    clarified - the problem is not so much man in the middle attacks but more someone decompiling the client and impersonating it
    – davidkomer
    Mar 29, 2015 at 7:11

1 Answer 1


Instead of using a hardcoded key, you should use mutual SSL authentication. Using an obfuscated key, doesn't add any security, certainly not when you're already using SSL.

  • Oh interesting... not sure why nobody mentioned that in the linked question... I will investigate this. Thanks!
    – davidkomer
    Mar 29, 2015 at 7:13
  • 1
    After looking- this seems to be identical to the above, only needlessly complex, because a private key must still be stored in the client for this to work.. and therefore it goes back to the problem of an impersonator.
    – davidkomer
    Mar 29, 2015 at 7:21
  • 1
    Per client key. That's the best practice. Mar 29, 2015 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .