3

My aim is to have an (iOS) app in which the user would login, then on sucsessful login, gain access to additional information over an encrypted webservice (undecided).

From research, I understanding encryption techniques of diffie-hellman key exchange, and 'signatures' using HMAC with secret key (from the diffie-hellman).

Further research lead me to HTTPS to ensure no-eavesdropping.

However I'm now a little confused as to what I would need to do over the HTTPS connection to ensure that the login data is secured between app & server.

  1. Is HTTPS enough security to pass POST 'username' & 'password' data down the line to the server on its own? or would an additional security such as a hash of the password be needed?

or

  1. Would I need to implement a full key exchange + request signature (and at some point an Access Token), over an HTTPS connection?

I'm unsure where to draw the line with encrypting.

4

HTTPS is more than security enough to send and receive information, don't start implementing your own security as HTTPS will take care of it for you. It provides:

  • Confidentiality
  • Integrity
  • Authenticity

The biggest caveat when writing mobile applications is to verify the the behavior of your application when it receives a certificate exception.

With regard to hashing the password, it's not really useful as the password will be whatever you send to the server, so replay attacks or sniffing would still be possible, even when you hash your password. Fortunately it will not be possible to view what's being sent over your connection as they're you will be using HTTPS.

In regard to your access token, you can just use a session token as you would use with any other web application. If you need a RESTful service you will need to send the username and password on every request.

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.