0

I have been looking into REST authentication schemes (many discussed on SO), and many of them seem to be overly complex for my purposes. I have formulated a simpler scheme from elements of the more complex ones: but I would like to know if there are any security holes in my approach.

Influencing factors:

  • TLS everywhere is too slow and resource heavy
  • I do not require security against eavesdropping as all information is public.

Proposed authentication scheme:

  • "Sign up" and "Login" are achieved via a TLS connection. On Login, a username and password are supplied and a shared secret key is returned by the server (and then stored in local storage by the client e.g. HTML5 local storage, App storage, etc).
  • Every other request takes place over cleartext HTTP

Client side algorithm:

  • Before sending, every request is "salted" with the shared secret key and an SHA hash is taken of the salted request.
  • This hash is inserted into the request in a custom HTTP header.
  • The salt is removed from the request.
  • The request is sent with the custom header.

Server side algorithm:

  • Server isolates and removes the custom Hash header from the request.
  • Server salts the request string with the shared secret key.
  • Server takes the hash of the salted request and compares it to the value of the custom hash header.
  • If they are the same, we have identified which user sent the request and can proceed with authorisation etc based on this knowledge.

Are there any vulnerabilities in this scheme that I have overlooked?

Ephemera
  • 8,672
  • 8
  • 44
  • 84
  • When in doubt, refer to http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own – CollinD Sep 25 '15 at 04:32

2 Answers2

1

I would question your assumptions here.

TLS everywhere is too slow and resource heavy

TLS is becoming almost ubiquitous for APIs and one reason is because it is now relatively cheap for both clients and servers to support it. How much overhead? As usual "it depends" but certainly negligible enough for most modern APIs, even mass-consumer APIs like Facebook and Twitter, to be moving towards using it exclusively.

I do not require security against eavesdropping as all information is public.

This is a common myth about TLS. Even for public data, consider the implications:

  • Any intermediary agent can inject their own requests and responses. It could be junk, malicious, subtly incorrect, whatever. Secure communication is not just to keep the content private, it's also to maintain its integrity. (A common example is telcos and hotels injecting ads into websites.)
  • The data may be public, but the traffic may still be sensitive. What if you could monitor Apple's Wikipedia requests? Would it be interesting if there was a spike in requests to car-related articles? Without TLS, intermediaries can monitor requests a user is making.

None of which critiques your algorithm. You could ask on Cryptography Stack, but it's considered fairly risky to roll your own authentication and rarely worth it nowadays.

mahemoff
  • 44,526
  • 36
  • 160
  • 222
0

What you are describing is an MAC based authentication scheme. Instead of rolling your own implementation, you should look at Hawk or AWS authentication schemes.

A downside of such an authentication scheme is that the server that needs to validate the request needs to talk to the authentication server to get the secret key. This impacts the scalability of the system in a negative way.

Token based authentication schemes can validate the request without going back to the token issuing authority due to digital signatures.

Finally, I agree with @mahemoff that TLS is becoming ubiquitous and very cheap. Actually, depending on the circumstances, HTTPS may outperform HTTP.

MvdD
  • 22,082
  • 8
  • 65
  • 93