Re: Authentication in 1.3 (was Re: State of Perl-based database setup utilities for LedgerSMB 1.3)

["David F. Skoll" <..hidden..>]

On Sun, 29 May 2011 00:07:42 +0200
Erik Huelsmann <..hidden..> wrote:

[...]

> > It also makes testing annoying because when you blow away a test
> > database, you also have to remember to blow away any LSMB users.  If
> > auth info were stored in the database itself, this wouldn't be a
> > problem.

> Neither will it be a problem if you do your testing on a separate
> PostgreSQL cluster, which can be easily blown away after testing:
> pg_dropcluster <clustername>.

pg_dropcluster requires root access whereas dropping a database
does not.

[...]

> It'd be a shame to see you go looking for another solution instead of
> staying with LSMB. However, other than that you regard the current
> decisions as unfortunate, I haven't seen any reasons why the current
> scheme is the badest move in all of LSMB's history.

It's not the worst, but I think it's a bad move because now important
data about the LSMB installation is separate from the LSMB database.
(Roles in Pg are global for a given cluster.  If Pg supported per-database
roles or roles with namespaces, I would be less opposed to the idea.)

> Because of the number of CVEs with vulnerabilities for webapps with
> login requirement, I think it's rather hard to create a well working
> webapp with login capabilities.

? But to use Pg authentication, you're still going to need to pass a
username and password across the HTTP session and that's usually where
any webapp vulnerability lies.  (Except that gaining credentials of
a Pg user might be much more useful to an attacker than gaining an
LSMB application-level user.)

Also, I don't see how you can use Pg auth securely without passing the
username and password for each page request, which means using HTTP
Basic Auth over HTTPS.  And Basic Auth is a real pain because there's
no standard way to log out other than closing your browser.

> To me the solution to hand off the login process to another (much
> more experienced and tested) party seems like a reasonable way to
> mitigate risks. Now, I'm open to other lines of reasoning and other
> technical requirements, but since this is accounting data, I sure
> would like to avoid any chances for unauthorized access.

Well, sure.  I would never open my accounting webapp to the Internet
at large.  We use firewall rules to restrict access to our LAN and
VPN.  Even with Pg auth, I would not change that policy.

If you do want to build a webapp robust enough to be open to the whole
Internet, I don't think using Pg auth over application-level auth buys
you anything because the security problems lie in leaking cookies or
credentials, not in the actual authentication mechanism being used.

Regards,

David.