0

I'm researching a new web-application that I want to develop using HATEOAS, RESTful principles. I'm looking into authentication schemes and the information for authentication of web-apps (via browsers, not machine-to-machine), seems a bit lacking.

After establishing an HTTPS session and initial log-on there doesn't seem to be any need for tokens, cookies, HMAC's, nonces, etc. to be passed. Nor does the Basic-Authentication or HMAC, OAuth, etc seem to matter: the HTTPS session is secure.

I'm probably missing something. Here's how I imagine my solution working: -

  1. User navigates to the login page of the web-application (HTTPS://acme.com/login)
  2. User specifies username and password
  3. Web-service validates the username and password: allows access to authorized resources

For the server to identify the authenticated user on subsequent requests, it could either: -

  1. pass the clear-text user name as a header or cookie - this is RESTful, IMO
  2. use the SSL session ID (if available to framework), looking up the user. This is not quite so RESTful as the session ID needs storing

I see no reason to use anything else than HTTPS. What am I missing, what vulnerabilities or missing functionality?

Thanks!

David Kerr
  • 1,376
  • 2
  • 15
  • 20

2 Answers2

3

HTTP Basic Authentication (i.e., username and password) + HTTPS is generally considered to be secure enough for most REST APIs, especially for internal use. However without a unique nonce (or transaction ID), you are vulnerable to replay attacks.

For example, imagine an attacker was able to record a genuine PUT request to create some new record in your database. They could then replay that message in a loop to launch a DoS attack on your API by filling up your database tables. Although the message was encrypted via SSL, it still contains valid credentials, so each replayed request from the attacker would be dutifully decrypted and successfully authenticated by your API.

HTTP Digest Authentication includes a nonce that changes for each request and is therefore considered a more secure option.

Adrian Edwards
  • 559
  • 5
  • 8
  • +1 for the replay attack and overcoming via Digest Auth. – David Kerr May 15 '14 at 06:49
  • I think HTTPS actually protects against replay attack.. see http://serverfault.com/questions/32473/does-https-include-protection-from-a-replay-attack and http://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks – Daniel Jun 14 '14 at 00:27
  • @Daniel Yes, you are right - usually. I do note however that comments to those answers leave some doubt. My takeaway was that the HTTPS standard should prevent against replay attacks, but some *implementations* of that standard might not. – Adrian Edwards Jun 19 '14 at 05:00
1

You have to define security here. SSL is fairly secure (despite there being issues recently with OpenSSL/Heartbleed).

However, as I see you are using a username and password/login, why not combine HTTP Basic and HTTPS? Most frameworks support basic auth, so. Simply authenticate the user every time you make a call. This is the only way to be RESTFul with Authentication, as you want to be stateless.

Zerkz
  • 686
  • 1
  • 6
  • 25
  • I've evolved my "architecture" and I'm now thinking of making my app a server-driven, with client-side (browser) progressive enhancement. It will still be RESTful, so drivable from other types of client (JSON/XML/HTML representations). But how can I do LOGGING OFF with Basic or Digest Auth? I can do it easily with a custom client, but how via a browser? – David Kerr May 15 '14 at 06:54
  • My guess is that you could delete the Auth header for basic. Im not 100% familiar with Digest besides the basic premise. – Zerkz May 20 '14 at 12:22