0

I have an application running on a server, that has an exposed socket to the Internet to communicate with client that is/are application(s) on a phone. How would one go about properly securing the access to the server, if one is not sure he could trust the client to store secrets?

What I mean by not trusting, is that for example if I don't want to store symmetric encryption key on the device, and I'm not sure encrypting messages with public RSA key is good enough since someone could just repeat message to the server..

TSL on the other hand seems to be geared towards client recognizing whether he can trust some server..

What would be a good way to start implementing a secure access from the client towards the server, and server to be able authenticate the client ?

1

Authentication is about reliably recognizing who is at the other end. Since, from the server, you "see" the client only through network packets, and since everybody can buy the same kind of hardware, you may hope to properly authenticate a specific client only if that client is able to compute things that other systems would not. This implies that the client must know some "secret". There is no avoiding it. If no secret can be stored client-side, then authentication from the server is hopeless.

Now, it so happens that in the case of a phone, the client system comes with an appendage usually designated as "human". There is a (loosely maintained) one-to-one relationship between a phone and its owner. This means, in your context, that the client-side secret can be stored in the device itself, but also in the brain of the human user. We call that, technically, a "password".

Alternatively, there is a reliably stored secret value stored on the phone side: it is the key in the SIM card. That specific secret is what is used by phone companies to distinguish phones from each other, and all the billing is based on it. You might be able to leverage that authentication, but only by integrating with the phone companies; you don't do that with a mere "server on the Internet". A practical implementation would be the following:

  • Client app connects to your server (with some appropriate protocol, typically SSL/TLS).
  • Server sends a SMS to the user, containing a random numerical code.
  • User reads the SMS and types back the code in the app.
  • The app sends the code to the server.
  • The server sees that the code sent from the app matches the one it just sent by SMS, and is happy.
  • Hi Tom, and thanks for your input. I thought about similar thing, but that would become fairly tedious after a fashion, wouldn't it? What about some type of login token on top of SSL/TLS ? Such as server sending a onetime login token, that can only be used once to initiate a connection - this way user without the certificate cannot do a "replay" login ? As you can probably see, this is a new area for me so any pointers towards right direction to read up on would be also greatly appreciated :) – julumme Aug 15 '14 at 1:02

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.