Re: Working on a security best practices document

[Michael Richardson <..hidden..>]

>>>>> "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...  
  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...

    Chris> Hope this clarifies the problem.  Pg supports Kerberos auth
    Chris> so if we get a kerberos ticket we can use that.  However, I
    Chris> can't see a secure way of doing http-digest auth in this
    Chris> environment.

  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.
  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.
  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. 
  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...
  
-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] ..hidden.. http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.