[Melbourne-pm] Web auth meth
Daniel Pittman
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[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.
More information about the Melbourne-pm
mailing list