cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: HTTP Basic Authentication Is there hope?
Date Mon, 12 Feb 2007 15:38:32 GMT

I tend to [snip] quoted text a lot, so please pardon me if any of the  
responses appear out of context.

On Feb 12, 2007, at 9:27 AM, Glynn, Eoghan wrote:
>
>> Aside from the *bad practice* of keeping user name/password
>> combinations in unencrypted files,
>
> I don't agree with you here that this is necessarily bad practice. In
> fact some form of it seems unavoidable to me in the general case.

I think we could go on and on arguing the relative merits or demerits  
of storing passwords on the file system.  I agree that there are  
cases in which it's needed -- as you've identified, unattended  
startup/clients.  Some vendors attempt some sort of obfuscation in  
these cases, but this is pretty much pointless, as a secret just gets  
embedded in the code somewhere.  (Google Steve Job's recent tirade on  
DRM, for why this is basically pointless)  So yes, I agree, you're  
leaning on OS security in this case, and that's okay, in a limited  
set of cases.

In any event, I think the whole discussion of persistent stowage of  
passwords is a bit of a tangent, in the discussion at hand, so I  
propose we drop this particular issue, or at least move it off to the  
side, as long as there is a programmatic way to configure this  
information.  (I'm still trying to understand the model enough to see  
if such programmatic config is possible)

> In particular, since the creds are effectively sent in the clear  
> (modulo
> base-64 encoding), surely if we want to keep these creds secret,  
> then it
> makes absolutely no sense to use basic auth over plain ol' HTTP?
>
> Rather, auth based on this scheme should *only* be used over HTTPS.

Exactly.  The question is, how do we enforce this condition?  Seems  
to me the runtime needs to know somehow that the target has been  
authenticated in some manner, and in the case of HTTP, SSL is pretty  
much the only game in town.  (Other transports may have other  
authentication mechanisms).

> We could enforce this by ensuring that the AuthPolicy is  
> accompanied by
> an appropriate setting of the SSLClientPolicy. But forcing the  
> issue has
> the downside of excluding a valid "weak auth" use-case ... e.g.  
> where we
> don't care if the creds are stolen because they're not protecting
> anything sensitive, but instead just drive some insecure  
> personalization
> logic in the endpoint. Or say the VPN use-case, where HTTP is OK as  
> its
> tunneled securely.

I'm not sure how enforcing this would exclude the admittedly weak use  
case -- certainly any behaviors here could default to the recommended  
best practice ("Never, under any circumstances, reveal a password to  
an unauthenticated peer").  Any desired knobs could then be used to  
tweak this behavior, e.g., to turn off the requirement.

An aside: I agree that there are cases where HTTP/BA over an  
unprotected channel are potentially useful, but I'd like to think  
these are fairly degenerate cases.  The VPN case is dangerous,  
because VPN traffic protects networks, not endpoints.  So if you  
really do care about passwords, you kind of have to bend over  
backwards with your routers to ensure no one isn't listening in  
promiscuous mode somewhere on your network.  It's doable, but it's  
relying on a lost of costly infrastructure.  If we can agree that  
this case is degenerate, then I propose we move on.

>
>> We would like to examine certain aspects of the endpoint
>> before we start *exposing usernames and passwords to
>> everybody* with a pretty flower.
>> There is no apparent way to do this in CXF's use of HTTP.
>
> Well to an extent there is some control here - we can configure the
> SSLClientPolicy to require that the endpoint has a trusted cert.

Okay, now that's interesting.  What would we need to do to do this?

(I snipped the whole discussion of server interceptors and 401 --  
sounds like an implementation detail I'm unfortunately not prepared  
to comment on, and I'm not sure how relevant it is to this discussion.)

> Ok what we do now is what you might call preemptive auth, in the sense
> that we send the Authorization header up-front without waiting to be
> asked for it via a 401 challenge. Yes we could wait for the 401,  
> but in
> either case, trust establishment cannot be done via Basic auth alone.
> IMO at least in order to mean anything, its got to be coupled with
> HTTPS.

I think that's just the point Polar made -- sounds like everyone's in  
agreement on this.

>
>> Even this java.net.Authenticator is woefully inadequate as
>> there is now way too look up an SSL authentication on the
>> HttpURLConnection.
>
> Do we really need to access the full details of the SSL authentication
> at this point? Would a check via Authenticator.getProtocol() that  
> HTTPS
> was indeed used, coupled with the client's knowledge of and control  
> over
> its own local truststore, not be sufficient?

I think we might.  For example, it may not be enough that the  
endpoint uses SSL.  What if, for example, you're using DH anonymous  
cipher suites?  All you get there is data protection, which if you  
think about it, is vulnerable to man-in-the-middle attacks (in which  
case you don't really get data protection at all).

There may also be cases in which, say, for some authenticated  
endpoints, you are willing to disclose a password (it has a key  
signed by Zeus), whereas others you don't.  So yeah, some details  
into the security features of the target could definitely be of use.

I'm also not sure if the coupling with control over the local trustdb  
is enough.  How does the runtime know what the trust policies are in  
effect?  If it's something that is outside of the control of the  
runtime, but rather at the discretion of the administrator  
("Configure your endpoints thusly"), I suppose that's an approach one  
could take, but there's very little you could say in terms of  
assurance, at that point, and I think what we are after is wiring  
some sort of hooks into the runtime in order to be able to make  
assurance arguments about its behavior.

> Here's the crux of the issue, what's a "good security solution", and
> what sort of underlying mechanism is required to supply this goodness?
> Is it reasonable to expect to able to build "hardened" security on a
> foundation as shaky as Basic auth? There are other, less weak, HTTP
> authorization mechanisms (Digest, NTLM etc.) that we could consider
> instead.

Well, as Dan suggested, the same issue comes up with the WS-Security  
username-password profile.  If you're going to send a username and  
password, you are going to need to ensure that the endpoint you're  
sending to is trustworthy.  You may want the same assurance with  
other profiles.  (Won't go into the details, but SAML through SOAP  
comes to mind).

Getting on to what I interpret the main point of the post, the  
question seems to apply to the granularity of the effective policies  
used at a client endpoint (or server, but I won't go there):

  1. When endpoint policies are specified via config (leaving aside  
the question of programmatic configuration), the policies are  
identified in a bean, and are based on a QName.
  2. In the case of HTTP/BA, the effective policy may be to send a  
username and password.
  3. It seems possible for more than one client endpoint (potentially  
referencing 2 different endpoints) to be associated with, or  
identified by, the same QName.
  4. Therefore, it's possible for a client application to  
inadvertently send its username and password to these 2 services,  
irrespective of any authentication that has or has not occurred of  
said targets.

I propose we stick to this issue (if I've characterized it  
correctly), and come to agreement about whether it is or is not a  
problem, and if it is, how we rectify it.

Thanks,
Fred

Mime
View raw message