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

[John Locke <..hidden..>]

Chris Travers wrote:
>
>
> On 10/2/07, *John Locke* <..hidden.. <mailto:..hidden..>
> > wrote:
>
>
>     First off, how can you do http auth using Javascript?
>
>
> One option is to grab the username and password from the form, make
> use XMLHttpRequestObject to make a request with that auth information
> and then redirect to the next page.  The big issue here is that some
> browsers may not support this (I know some versions of Opera and
> Safari are known to have some issues with auth credentials and this
> method).  Of course, if it doesn't work you get a popup asking for
> credentials.  At least we could filter out known problem browsers and
> just ask for the auth information directly.

Wow. It had escaped my attention that XHR could set http auth. Very
cool--I like this approach. Seems like an easy fallback approach would
be to check to see if http auth was set, and if not, generate a simple
link to a URL that requires authentication. When this page is loaded,
replace the link with the login form and hook up the xhr actions. That
way if JS is turned off, users don't get the form, and can follow the
link and log in using whatever auth method is available. For deployments
that use client certificates/Kerberos/other auth methods, administrators
can just set the default page to be the main application page instead of
the login page.
>
>
>
> Well, it doesn't handle everything.  There is a question as to what we
> do when a session expires.  One option is to check to see if the auth
> used a raw http request directly last time and if so, simply send a
> 401.  If it used the login screen/JS, we use a similar measure this time.
>
> In short we go from login/session to login/session/password used on
> every request.
>  
Nice. I think this is the best option.

>
>     >
>     > The major issue with storing the information in the session
>     object is
>     > that a database superuser could review all passwords of all
>     currently
>     > logged in users.  I don't think that this is acceptable as it both
>     > allows a set of trusted individuals to bypass security of the db and
>     > also undermines basic security mechanisms of PostgreSQL as a whole
>     > (which we rely on).  If anyone has better ideas, I am open to them.
>     > However, this will also put us within striking distance of
>     transparent
>     > single signon support (for things like Kerberos).
>     >
>     But wouldn't a database superuser be able to do anything they want
>     with
>     the data?
>
>
>
> No.  Normally the user passwords are stored via an MD5 hash, salted
> with the username.  Hence the superuser could see the hash, run
> cracking software on it, etc. but could not generally see the plain
> text password.  If we store in the session, a superuser can bypass the
> hash protections that exist in the PostgreSQL system catalogs, which I
> think is a bad thing :-).

Well, I guess I'm thinking if the administrator is that motivated, it
wouldn't be hard to simply edit the Perl file that handles the request,
and add a few lines to log the http auth to a text file. Almost as easy
as finding sessions data ;-)

>
>
> In the past, I have stored the password separate from the login in
> clear text session files.  File permission becomes a big issue, and in
> those applications, there is no way to know who is currently logged
> into the system.  LedgerSMB is different in that we also store the
> login in the db session, meaning that now one can know this.  In
> either case, however, the administrator can determine a few passwords
> quickly and could then attack user accounts.
I guess I don't see how you can stop this--you're just moving the attack
surface around. Can't eliminate it completely.

>
> The danger in attacking user accounts is that it allows an
> administrator to effectively impersonate another user for an extended
> time without getting caught (of course, tampering with the pg_hba.conf
> could do this as well but at least there you have the chance of
> determining what happened, and the more you force someone to cover
> tracks in an ongoing attack, the more likely it is that there will be
> a signature left behind).  In short, one of the principles I use would
> be compromised in this regard, namely that when faced with two options
> which pose similar security risks, choose the one which creates the
> largest signature on the system.
>  
Agreed. Logging http requests involves modifying a core file (though
that's really all it takes), and this could be detected using Tripwire
or similar file checksum systems. But who's watching the watcher?
Ultimately, you have to trust somebody...
>
>
> There are known issues on auth credentials on XMLHttpRequest objects
> in some browsers, which may reduce our ability to automate it on
> Javascript.  In particular, I don't know which versions of Safari and
> Opera may run into problems with the browser not properly handling the
> credentials.
I like your browser blacklist idea to skip the xhr auth. Maybe have a
cookie tied to a checkbox to skip the login form that users can
check--this could allow for other http auth methods if a site supports
multiple, as well as allowing users to always skip the login form if
they have a buggy browser.

Cheers,

-- 
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com