Custom web authentication scheme

Question

For a project at work I'm currently implementing a not too large webservice. For reasons of learning something new I tried making it a REST service, which then prompted the issue of authentication. I eventually settled on HTTP Basic Auth since it has the benefit of being supported by pretty much any HTTP library, even though I had to implement the server side myself.

Yesterday a colleague suggested I should just send the hashed password instead of username and password in plain (eventually the service will be accessible only via HTTPS so I considered Basic Auth not to be a security problem, but let's leave that aside for now). But I wondered what it actually would change, security-wise.

Sending the hashed password basically means a bcrypt hash since that's what we store in the database. Which means I would first have to send the client the work factor and salt so they can arrive at the same hash I have in the database. This requires a challenge-response mechanism which already is much more complicated to implement.

Then there is the point that the hashed password the client sends for authentication essentially functions like a plain-text password, as far as auth is concerned; and could easily be replayed, should someone get hold of it.

So basically, what I found:

• It solves sending the password in plain, similar to Digest, as opposed to Basic
• It doesn't solve the replay issue (Digest does, due to using a nonce) of Basic
• It requires password hashing on the client with less predictable performance. E.g. smartphones likely require smaller work factors than desktop machines and the main consumers of the API would be smartphones and tablets. So we would have to reduce strength of bcrypt in that case.
• It would be far more complex to implement, both in the client and server, due to a custom challenge/response scheme and thus more room for errors. It probably goes against REST principles as well.

Did I miss anything? HTTPS solves the problems of Basic auth, as far as I understood and thus the custom scheme doesn't solve any actual problem, apart from developer boredom maybe. But I'm no expert on any of this.

Answer 1

You are basically right. In an authentication scheme where there is only one message, from client to server, whatever the client shows "grants access" and, as such, is password-equivalent and can be replayed. If sending the hash of the password works, then the hashed password is password-equivalent. Indeed, what your colleague suggests does not add security; instead, it adds a feeling of security, which is, all other things being equal, a bad thing.

HTTP digest is somewhat better because of the nonce, thus preventing replay attacks. A somewhat similar concept is one-time passwords: this is like HTTP digest, with a counter and/or the current time serving as nonce (see HOTP and TOTP.

Note, though, that even if you have a rock-solid authentication mechanism that could be safely played over plain HTTP, it would still be plain HTTP. An industrious attacker will simply observe the connection, wait for the authentication part to be finished, and then hijack the connection to send his own requests. HTTP Digest was designed at a time when most attackers were assumed to be passive, and it was (wrongly) supposed that active attacks were too hard to pull out. Modern networking has shown this idea not to be true. Therefore, SSL (HTTPS) is needed anyway so that the authentication part is really "authenticating" the communication. And if you have SSL, then Basic authentication (aka "show the password") is fine.

One may even point out that in order to support protocols like HTTP Digest, the server must more or less store the user password in cleartext or with reversible encryption, so that's actually weaker than the normal way of storing hashed passwords.