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

[John Locke <..hidden..>]

Chris Travers wrote:
> In going to native DB accounts, one of the difficulties we have to
> resolve is how to effectively authenticate serial requests.  The major
> problem has to do with how the password to the database is stored.  I
> am going to suggest that we move to using HTTP authentication as the
> primary mechanism of authentication and automate this from the login
> screen where possible using Javascript.  A secondary method could be
> offered where the passwords are stored in the db, but this has more
> serious security concerns associated and therefore I would suggest
> that we do not go that route.
This is an extremely difficult problem I've wrestled with a few times,
and have not come up with an ideal solution.

First off, how can you do http auth using Javascript? Is that even
possible? If so, we might be able to use Digest authentication to handle
hashing the password--haven't used that much to know its ins and outs.
If not, well, http auth handles the browser to server session handling
nicely, at the expense of a worse user experience.
>
> 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?

I don't see a better alternative here. I think you have to store the
password in a session, if you need it to authenticate to the next tier.
The decision is, where? Seems like these are the options:

1. Browser cookie that's sent each request
2. HTTP Auth that's also sent each request
3. Persistent session on the server, with a session id passed from the
browser:
3a. Store session in some sort of file
3b. Store session in temporary table/session table
4. Use some 3rd party auth system to authenticate a user request (still
using #1-3), and proxy the authentication to Postgres.
Kerberos/LDAP/Active Directory/whatever.

I don't like #1, since these get stored on the client machines and may
be sniffed out through all sorts of methods.

#2 is the easiest (in my experience) to implement, but very difficult to
have an effective "log out", and it has the worst user experience.

#3 needs to store the db password in clear text somewhere on the system.
But aside from people logging into the system directly (shell or db
connection), it should be possible to protect this data from access
through the normal interfaces (and shut down all the other interfaces).
Also, it's relatively simple to kill sessions, enforce logout behavior,
detect IP address changes of the client, etc.

#4 seems like it adds another layer of complexity to the whole system,
and I've never dug through this to even know where to start.

So some version of #3 seems like the best option, unless somebody has
some trick for doing this that's completely escaped my notice...

Somebody is going to have the skeleton key. How do you protect data from
root? I think the answer is, you can't. The best you can do is provide
audit trails, logs that can provide evidence of tampering. And then
restrict direct access to the machine and database to the smallest
number of people possible. If someone has superuser access, what's to
prevent them from changing the code?

> The big disadvantage is that some browsers may handle authentication
> differently and we will have to address this.
Not sure what you mean here, unless you're talking digest versus basic auth?


Cheers,

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