[Melbourne-pm] Web auth meth
daniel at rimspace.net
Wed Sep 10 17:55:49 PDT 2008
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 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
> 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
It is entirely true, but perhaps a bit limited in view.
> Consider a standard web form that asks for user name & password. It
> 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://firstname.lastname@example.org/...
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
> 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
> The disadvantages seem to be every framework doesn't want to work this
Most of the frameworks I have dealt with can be convinced to trust
Apache authentication which, as Scott notes, has significant advantages.
 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.
 Sending another 'auth required' and having the browser prompt the
user is really, really user hostile. Which sucks.
More information about the Melbourne-pm