On Fri, Feb 5, 2010 at 11:39 AM, Michael Richardson
<..hidden..> wrote:
>>>>> "Chris" == Chris Travers <
..hidden..> writes:
Chris> How would one take an HTTP Digest Authentication token and
Chris> log into the db with it?
>> From what I understand about the users' table (in 1.2 and SL)...
>> The user connects, provides a password, and if it checks out, we
>> use the database credentials from the users' table to connect.
>> The columns are not encrypted AFAIK.
Chris> Right, but that isn't how we do things in 1.3. The users
Chris> table doesn';t include password information at all in 1.3.
Chris> Instead we take the credentials sent by the browser and use
Chris> them to log into the db. If the login is successful and a
Chris> user configuration exists, the user is allowed to use the
Chris> application. The password data in 1.3 is stored in the
Chris> pg_catalog.pg_authid table because the users are full
Chris> database users.
Right, I wasn't completely aware that this has happened.
This is kinda neat actually, because in theory, if one can devolve all
consistency checks to the database (with constraints, and stored
proceedures), then it really doesn't matter if there are priveledge
escalation attacks in the front end...
Yep :-)
It also means that one can write new client systems that aren't
HTTP/HTML web based. This could mean full client/server systems, ones
written in _javascript_ that use a RESTful interface into the database, or
even other kinds of brokers that might live in the cloud...
I imagine that this was your goal...
Exactly.
I agree, we can't get to http-digest for this unless Pg has a way to
help us. I think it does...
Yeah, so the md5 method actually is pretty much the same as
HTTP-Digest mode, I think. The database has to store the password text
in a format that can be hashed again.
Well, sort of. The hash is rehashed, which is a problem.
The problem is that this just isn't going to work unless the HTTP
connection terminates on the Pg daemon -- and the formats, mechanisms
will be different.
Right.
Same thing for certificate or Kerberos login to the database --- a
great idea, but it requires that the client's web browser interact
directly with Pg.
Not necessarily. Basically with Krb, we get the web browser to send a ticket to the web server, which we authenticate and get a session ticket. That session ticket can then be used to log into the db from the web server, but it means two hits against the KDC for validation.
Given that it's all open source, and one could easily arrange a trust
relationship between a mod_authenticate_against_Pg and a Pg daemon with
some source changes to both, I think it's possibly very doable..
it might be. I am wondering what the tradeoffs would be to move to unencrypted passwords on PostgreSQL would be though. In general, I suspect decentralized vulnerabilities which can be mitigated by SSL are better than centralized ones.
Best Wishes,
Chris Travers
.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users