[Melbourne-pm] Web auth meth

[Daniel Pittman]

Tim Hogard <thogard at abnormal.com> writes:

> I'm about to start a new project that is somewhat largish in scope and
> part of the workflow design we have involves using forms to login.

That is, generally, a good plan: it allows you to make the login page
user friendly, in a way that browser auth dialogs are not.

It also allows you to implement "log out", a feature that is often
desirable[1] within the security model, and is generally more familiar
to end users.

> That in its self is about as earth shattering as the LHC but the
> discussion turned into what framework we intend to use and how we are
> going do the user authentication.  It seems to be that every web
> browser on the planet know about Basic Auth and most know about Digest
> Auth and Digest Auth seems to be about secure as anything when used
> with SSL.

As others noted, digest auth still has risks.


> So why reinvent a session logging system when there doesn't appear to
> be a need?

The ability to terminate the authorization from the server side in a
sane fashion.[2]

> So I've been asking around looking for why some of the more complex
> systems are used.  The biggest reason cited so far is "You can't make
> a nice looking login form"... hmmmm.... I think thats not entirely
> true.

It is entirely true, but perhaps a bit limited in view.


> Consider a standard web form that asks for user name & password.  It
> tends to have a target of a url but if thats a javascript that request
> http://$username:$pass@mysite/hidden.gif and then goes to the a page

This doesn't always work, as it can conflict with the security setup of
the browser or force user interaction.  As far as I recall from testing
this, some time ago.

Also of note: this technique was used for "phishish" attacks some time
ago, in the style:  http://www.microsoft.com@foo.bar.com/...

This means that using it in your software risks triggering defences
against the same.

> (that requires basic or digest auth) then all the user sees it the
> page and never sees the ugly browser based login window.  The
> advantages of this type of login scheme include the browser keeping
> track of the user credentials in as secure of a way as it can, users
> without javascript can still login (entering their details twice),
> pages can be deep bookmarked, scripts using wget and its clones can
> all get at any content, it works with users behind bad proxies where
> every request can come from a different IP address, scripts can be
> written in anything and static pages only need a core web server.

Seems reasonable to me.  Assuming the technical issues above are
resolved, supporting digest auth as well seems a decent plan.

You might want to have the base HTML contain a link to the secure
content, then draw the login form with JavaScript, so that
non-javascript users only get asked once for authentication.

> The disadvantages seem to be every framework doesn't want to work this
> way.

Most of the frameworks I have dealt with can be convinced to trust
Apache authentication which, as Scott notes, has significant advantages.

Regards,
        Daniel

Footnotes: 
[1]  Have you ever tried to work out exactly what you need to close to
     get rid of basic auth in some random web browser you never heard
     of?  I /never/ want to have to do that again.

[2]  Sending another 'auth required' and having the browser prompt the
     user is really, really user hostile.  Which sucks.