On Thu, 2005-12-01 at 13:08, Don Russell wrote:
> >
> >>I have a web appl that uses status code 401 (authorization required) to
> >>challenge the user for an id/password. The client then responds with the
> >>http-authorization header etc. All is well.
> >>
> >>But, I want to make a more 'friendly' log on page:
> >>So, my server sends a page with status 200 (OK) with a simple form with
> >>two fields: userid/password. (The rest of the page content is the
> >>friendly fluff, not relevant to my problem)
> >
> >
> > Usually the way this is done is to turn off basic authentication
> > and use something cookie-based instead. You can probably find
> > a routine in whatever server scripting language you prefer
> > to handle the login and checking if you don't want to write
> > your own. A side effect is that you can add a 'logout' button
> > to delete the cookie where the only way to get rid of basic
> > authentication is to shut down the browser.
>
> OK... thank you... that idea occurred to me, but it seems less secure.
> It seems like such a simple need: a way to tell the browser, "Here, use
> this page to prompt for the userid and password".
>
> It's too bad that by providing a "splash page" to log on from, that
> reduces the overall security of the site.. maybe I'm missing something. :-)
What you are missing is that basic authentication is about
as insecure as it gets since the login and password are passed
in plain text on every request unless you run everything over
https and there is no way to make a browser forget them other
than exiting every instance. With cookies you can be more
creative about what you put in it, how you encode, how long
it's valid, etc. If security is a concern you should be
using https anyway and cookies that only persist for the
current session.
--
Les Mikesell
lesmikesell@xxxxxxxxx
