[Zope-dev] question: forcing https for authentication

[Oliver Bleutgen]

Jamie Heilman wrote:
> Well its true you can't prevent users from compromising their
> credentials, but you can prevent users from coming in the wrong door,
> as it were.  I'm not clear on which one you really hope to accomplish,
> though from your proposed modifications it looks like the latter.
> Preventing users from compromising their creds can only be effectively
> done through education.  For example, even if you used client
> certificates (which, afaik, are only used once an encrypted channel
> has been established) instead of basic auth there's nothing to stop a
> user from giving their cert and any requisite ancillary usage
> information (like the passphrase to decrypt it) to somebody else.

Granted. I indeed want prevent users from coming in the wrong door. And 
it would really help if there wasn't a wrong door at all - therefore my 
question ;).


>>The only ideas I have to tackle this without modifying zope itself are
>>
>>- customize all pages which need authentication to check for "https://" 
>>in one of the relevant REQUEST attributes and do a redirect if not.
>>- use apache with some magic to trigger redirection if it encounters 
>>authentication headers in the request.
>>- use apache with some rewrite magic trigger redirection when a 
>>substring like "manage" is found in the request.
>>
>>These alternatives are neither elegant, nor really secure.
> 
> 
> I would agree the first two aren't sane, the third however is as good
> and as secure as you're going to get.  Techniques for accomplishing it
> have been discussed on the zope list before and are undoubtedly in the
> archives.  

> The mods you've posted with respect to guarding the
> WWW-Authenticate header aren't likely to work, and certainly wouldn't
> be flexible enough to allow, for example, mandating SSL usage for all
> /manage* requests while allowing clear-text basic auth for other
> restricted areas.  Apache rewrite rules OTOH are flexible enough to
> allow this.  I'm unclear as to why you consider it to be insecure,
> care to elaborate?

The third alternative is indeed secure compared to the other two, in 
that it prevents plaintext credentials from going over the wire - as 
long as you remember to use always names like manage*. It's factually 
more insecure than my idea in that even ZMI's methods can be accessed 
with mangled names (e.g. http://server/manage/index_html). It's 
cumbersome because newly installed products always have to be checked 
for the method names.

It's shaky, because if your filtering is too broad, better don't give 
the "corporate management profile" page an intuive id ;). And it's 
clearly worse performance wise for the typical use case, because you now 
get a load of rewrite stuff for any URI which has to be processed.

All these complications and administrative burdens alone lead in effect 
to insecurity.

The example code I posted was more or less to illustrate my intention, 
if I'd know where to implement such a hook, I'd probably try to make it 
  more flexible. Make it dependend from a startup flag, and check for a 
magic attribute in the acquisition chain perhaps, which prevents the 
redirect. Also allow for redirects to a different host.


cheers,
oliver