HTTP Basic Authentication instead of TLS client certification

Question

The answer below is from this question;

The awarded answer doesn't actually address the question at all. It only mentions SSL in the context of data transfer and doesn't actually cover authentication.

You're really asking about securely authenticating REST API clients. Unless you're using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API. SSL without client authc only authenticates the server, which is irrelevant for most REST APIs.

If you don't use TLS client authentication you'll need to use something like a digest-based authentication scheme (like Amazon Web Service's custom scheme) or OAuth or even HTTP Basic authentication (but over SSL only).

So considering I will use HTTPS without client certification my question here is poster says if we dont use client SSL certification server does not really know whom its talking to. What I understand here is if I use a authentication-token to access to authenticate the client against the server. Then server does not know whom is sending the token even if that token is paired with a user id in my servers database.

First of all

1-is this a real problem? If I especialy use Https?(without TLS client authentication)

2- and most important, assuming that is an important security flaw; How can Http basic authentication help here as poster mentioned? Http basic authentication just sends encoded username password in a header. So when client receives a token (in return after he sends his username password) then for the rest of his requests he will use this token in this header instead of password, and everything is fine all of a sudden?

Still Server does not know from where the request is coming from, maybe server has a valid token with a matched user in its database but unknown who reallysend it. (while I still see this very hard that the token would be stolen over https and used by someone else!)

Whenever I bring this subject I get replies.."Well..you send a token but server does not know whom send the token, not very secure" so I understand this as the browser keeps a sort of auth-certification and server knows where the request is coming from the right place THEN I can be sure that the paired user with that token (checked from my DB)is "really correct"

Or maybe what am telling here is not correct

Solution 1

[the] poster says if we dont use client SSL certification server does not really know whom its talking to.

That's not what I said :) This is what I said:

Unless you're using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API.

alone being the key word here. Also:

If you don't use TLS client authentication, you'll need to use something like a digest-based authentication scheme (like Amazon Web Service's custom scheme) or OAuth or even HTTP Basic authentication (but over SSL only).

In other words, TLS client authentication is one way of authenticating a REST API client. Because the original SO question was about SSL specifically, I was mentioning that TLS client authc is the only 'built in' form of authentication if you're relying on TLS alone. Therefore, if you're using TLS, and you don't leverage TLS client authc, you must use another form of authentication to authenticate your client.

There are many ways to authenticate REST Clients. TLS client authc is just one of them (the only 'built in' one for TLS and usually very secure). However, TLS is a network-level protocol and is perceived by most to be too complicated for many end-users to configure. So most REST API offerings opt for an easier-to-use application-level protocol like HTTP because it is easier for most to use (e.g. just set an HTTP header).

So, if you're going the HTTP header route, you have to use a header value to authenticate a REST client.

In HTTP authentication, you have a header, Authorization, and its value (the header name is rather unfortunate because it is usually used for authentication and not as often for access control, aka authorization). The Authorization header value is what is used by the server to perform authentication, and it is composed (usually) of three tokens

1. An HTTP authentication scheme name, followed by
2. white space (almost always a space character), followed by
3. The scheme-specific text value.

One common HTTP authentication Scheme is the Basic scheme, which is very... well... basic :). The scheme-specific text value is simply the following computed value:

String concatenated = username + ":" + raw_password;
String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());

So you might see a corresponding header look like this:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

The server knows how to parse the value. It says "Hey, I know the Basic scheme, so I'm going to take the trailing text value, base64 decode it, and then I'll have the username and submitted password. Then I can see if those values match what I have stored."

And that's essentially Basic authentication. Because this scheme in particular includes the submitted raw password base64 encoded, it is not considered secure unless you use a TLS connection. TLS guarantees (mostly) that prying eyes can't intercept the headers (e.g. via packet inspection) and see what the password is. This is why you should always use TLS with HTTP Basic authentication. Even in company intranet environments.

There are other even more secure HTTP Authentication schemes of course. An example is any scheme that that uses digest-based authentication.

Digest-based authentication schemes are better because their scheme text value does not contain the submitted password. Instead, a password-based-hash of certain data (often other header fields and values) is calculated and the result is put in the Authorization header value. The server calculates the same password-based-hash using the password it has stored locally. If the server's computed value matches the request's header value, the server can consider the request authenticated.

Here's why this technique is more secure: only a hash is transmitted - not the raw password itself. That means this technique can be used to authenticate requests even over clear-text (non TLS) connections (but you would only want to do this if the request data itself is not sensitive of course).

Some digest-based authentication schemes:

• OAuth 1.0a, aka RFC 5849.
• HTTP Digest Access authentication (used by browsers natively).
• Amazon AWS's custom scheme.

Amazon's and others like it are more secure for REST than OAuth 1.0a because they always authenticate the entire request - including the request entity payload (i.e. all the stuff after the HTTP headers too). OAuth 1.0a only does this for application/x-www-form-urlencoded content which isn't relevant for REST APIs that use application/xml or application/json payloads (which are most REST APIs these days).

Interestingly, OAuth2 is not digest based - it uses something I consider less secure, called 'bearer tokens' (which are honestly fine in many scenarios but still not as good as the digest schemes used in banking, military, and government communication).

Solution 2

When we talk about "authenticating a user", what we really mean is "checking that the user knows something nobody else should know". That "something" might be a password, a certificate, a hardware security token or even the user's retinal pattern, but in all cases it's the access to that information that we're really checking, not the identity of the user (whatever that really means) as such.

The point is that, in principle, all these authenticators could be stolen and used to impersonate the user. A password could be logged, a certificate could be copied from the disk it's stored on, a hardware token could be stolen (and possibly reverse engineered and cloned) and even the user's retinal pattern could, in principle, be scanned, recorded and faked. the best we can do is, in each case, to try to make this as "very hard" as possible.

Solution 3

Maybe I'm misunderstanding the question.

The answer you have quoted says to me that if you don't use some form of authentication, whether it is client certificates, HTTP BASICAUTH, or something else, the server doesn't know with whom it is communicating.

(Maybe that's okay for your application, maybe it isn't, only you can answer that.)

Stated in other terms, if you do use some form of authentication, the server does know with whom it is communicating; it is communicating with the "person" to whom the authenticated credentials belong.

In this context, authentication is the process of establishing identity via some credentials.

Authentication does not guarantee that the credentials have not been stolen. SSL assures (I wouldn't go so far as to say it "guarantees") the credentials are secure in transit between client and server.

When you use GMail, you're using SSL, how does Google know it's talking to you?

Comments

[Spring]

thanks!when you say "The server knows how to parse the value. It says "Hey, I know the Basic scheme, so I'm going to take the text value, base64 decode it, and then I'll have the username and submitted password. Then I can see if those values match what I have stored."

[Spring]

thats actually at the moment my code is parsing the http header doing that stuff not web server

[Spring]

to use digest I thought I have to use a "shared secret key" with client and it will make things complicated, but I see that I can use the user password as a secret key, so no extra work to do. correct?

[Les Hazlewood]

@Spring, you can use the user password as the secret key for digest authentication, but it is usually not recommended: if the user ever changes their password, their REST clients will immediately break! It's best to have a password for UI logins only and then use REST API Keys (id + secret) for REST logins (Stormpath does this for example). HTH!

[Gilgamesz]

@LesHazlewood , could you refer me to any book to read more about that subject and similar to?