I'm working on a REST API that will let an Android app communicate with a website. Sadly more than half of the people that are going to use it can't do so over HTTPs, so I will have to maximize security over HTTP.

What needs to happen is simply authenticating through a REST API, username/email and password.

I've thought about either hashing the password (or username+password) clientside and sending that to the server, but then you'd end up with simply a second password anyone could still auth with. Hashing the password clientside would even mean that if someone gets access to the database that person would be able to access all accounts.

What is a way to safely authenticate over HTTP? I have full control over both client and server so there's not really anything that's not possible.


3 Answers 3


Did you look into digest authentication mechanism?

It's better than clear user/password over HTTP. Still, there are some security problems with it (like MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode), but if you are in control of the client you can overcome it.


  • 1
    It's not really better than cleartext: the content of the messages can still be be freely read and unless you re-authenticate for each request, an attacker can simple reuse your authentication token to impersonate you (i.e. hijack your session).
    – Stephane
    Commented Feb 25, 2015 at 14:12

You can create a Diffie-Hellman exchange over the REST API.

First the client request a set of parameters and the server creates g, a and an ID to identify them in the servers cache. It then sends g, g^a and the ID back to the client.

Then the client can generate a b and calculate g^(ab) and extract a key from that to encrypt the password. The client then sends g^b the encrypted password and the ID back to the server.

The server can then get a from its cache based on the ID and calculate g^(ba) and extract the key to decrypt the password. After this normal salting and hashing operations should be done to store it in the DB and to verify it.

IDs should only be valid for a short time.

This is however vulnerable to active MitM attacks.

To circumvent it you can sign the responses of the server with a private key whose public key is known to the client.

  • Isn't this vulnerable to MITM attack? Commented Jan 26, 2015 at 10:08
  • 2
    an active MitM where the server is replaced yeah, that needs a separate authentication (signing the responses of the server for example). And replay will only work as long as the ID remains valid. Commented Jan 26, 2015 at 10:11
  • 1
    The need for DH authentication will incept a chicken-and-egg problem where something have to be disclosed in clear if you are not willing to adopt e.g. a PKI approach where your clients receive a public key to check authenticate the DH, in that case you would be recreating TLS. Commented Feb 25, 2015 at 15:22

you can completely remove authentication from your REST API and use a third party authentication instead.

you can program your API Client to first access a resource which requires the user to first authenticate to an external authentication provider securely. If the user is able to access to this resource, then they can continue to access the REST API that you are building.

You must log in to answer this question.

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