2

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.

1

You can create a Diffie-Helman 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? – S.L. Barth Jan 26 '15 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. – ratchet freak Jan 26 '15 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. – Stefano Sanfilippo Feb 25 '15 at 15:22
1

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.

http://en.wikipedia.org/wiki/Digest_access_authentication

  • 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 Feb 25 '15 at 14:12

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.