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 '15 at 6:13
  • I'm also confused about why you are encrypting the data again within an SSL stream.
    – schroeder
    Mar 29 '15 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 '15 at 7:11

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 '15 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 '15 at 7:21
  • 1
    Per client key. That's the best practice. Mar 29 '15 at 7:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.