Re: Re-authentication proposal for LedgerSMB 1.3 (HTTP Auth)

[Toni Mueller <..hidden..>]

Hi,

On Mon, 01.10.2007 at 17:29:36 -0700, Chris Travers <..hidden..> wrote:
> On 10/1/07, Joshua D. Drake <..hidden..> wrote:
> > Chris Travers wrote:
> > > On 10/1/07, Joshua D. Drake <..hidden..> wrote:
> > >> passwords will not be stored as plain text... they will be an encrypted
> > >> hash. I am not understanding the problem.
> > > Log in to LedgerSMB with your DB username and password.
> > >
> > > Click on a link.  How does the application know what password to use to log
> > > into the db?
> >
> > You hash and compare?
> 
> Ok, maybe I am not being clear.
> 
> To log in on the next page you need to provide PostgreSQL with a username
> and password.  How do we derive what password we send to PostgreSQL and
> where do we store this (it would have to be stored in the clear somewhere
> since we have to pass it via the DBI connect routine)?

I strongly suggest using the following authentication scheme, after
having battled non-cooperation between several authentication methods
for a while in a different context:

You have a username/password combination set for the application that
the application uses to request eg. authentication data from the
database. Alternatively, you leap and implement OpenID, which "solves"
all other problems for you.

Now, when the user is on the login screen, you grab his username and
password, hash, and compare with what's in the database. OR, you use
that data to authenticate to the database (should have pretty much the
same effect). If authentication succeeds, you open a session and set a
cookie to the user. Doing that session+cookie stuff has its own
pitfalls, but I've not yet been able to combine eg. 2x "HTTP Basic
Auth" or 1x "HTTP Basic Auth" + 1x "HTTP Digest Auth" (eg. when working
through a so-called SSL-VPN).

What you can do, however, is to modify the cookie on every request, so
stealing a cookie would not necessarily grant immediate access (it
would be invalid once the user has clicked another link). The big
drawback to modifying the cookie on every request is that this disables
working with several tabs open at the same time. OTOH, SSL should be
mandatory anyway and make cookie-stealing almost a non-issue.

JavaScript should IMO be out of the question, however, and only be used
for pure convenience functions. Accessibility should be a core
requirement.


Best,
--Toni++