Chris Travers | 2 Oct 01:54 2007
Picon

Re-authentication proposal for LedgerSMB 1.3 (HTTP Auth)

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.

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

The big disadvantage is that some browsers may handle authentication differently and we will have to address this.

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Joshua D. Drake | 2 Oct 02:01 2007

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


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

passwords will not be stored as plain text... they will be an encrypted
hash. I am not understanding the problem.

Joshua D. Drake

  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).
> 
> The big disadvantage is that some browsers may handle authentication
> differently and we will have to address this.
> 
> Best Wishes,
> Chris Travers
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ledger-smb-devel mailing list
> Ledger-smb-devel@...
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

--

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
			UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Chris Travers | 2 Oct 02:05 2007
Picon

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



On 10/1/07, Joshua D. Drake <jd-UrU3iCXxUysMNcg9MzyYcQC/G2K4zDHf@public.gmane.org> wrote:
-

passwords will not be stored as plain text... they will be an encrypted
hash. I am not understanding the problem.

Log in to LedgerSMB with your DB username and password.

Click on a link.  How does the application know what password to use to log into the db?

Best Wishes,
Chris Travers


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Joshua D. Drake | 2 Oct 02:13 2007

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


Chris Travers wrote:
> On 10/1/07, Joshua D. Drake <jd@...> wrote:
>> -
>>
>> passwords will not be stored as plain text... they will be an encrypted
>> hash. I am not understanding the problem.
> 
> 
> Log in to LedgerSMB with your DB username and password.
> 
> Click on a link.  How does the application know what password to use to log
> into the db?

You hash and compare?

Joshua D. Drake

> 
> Best Wishes,
> Chris Travers
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ledger-smb-devel mailing list
> Ledger-smb-devel@...
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

--

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
			UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Chris Travers | 2 Oct 02:29 2007
Picon

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



On 10/1/07, Joshua D. Drake <jd-UrU3iCXxUysMNcg9MzyYcQC/G2K4zDHf@public.gmane.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Travers wrote:
> On 10/1/07, Joshua D. Drake <jd-UrU3iCXxUysMNcg9MzyYcQC/G2K4zDHf@public.gmane.org> wrote:
>> -
>>
>> passwords will not be stored as plain text... they will be an encrypted
>> hash. I am not understanding the problem.
>
>
> Log in to LedgerSMB with your DB username and password.
>
> Click on a link.  How does the application know what password to use to log
> into the db?

You hash and compare?


Ok, maybe I am not being clear.

To log in on the next page you need to provide PostgreSQL with a username and password.  How do we derive what password we send to PostgreSQL and where do we store this (it would have to be stored in the clear somewhere since we have to pass it via the DBI connect routine)?

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Chris Travers | 2 Oct 02:30 2007
Picon

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

I.e. what password do we use to create our primary database connection for the application?

Best Wishes,
Chris Travers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Chris Nighswonger | 2 Oct 13:43 2007

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

On 10/1/07, Chris Travers <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.

I trust we will hash the password somehow before transmitting it from
the browser...

  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.
>
> 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).
>
> The big disadvantage is that some browsers may handle authentication
> differently and we will have to address this.
>
> Best Wishes,
> Chris Travers
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ledger-smb-devel mailing list
> Ledger-smb-devel@...
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
>

-- 
Chris Nighswonger
Network & Systems Director
Foundations Bible College & Seminary
www.foundations.edu
www.fbcradio.org
cnighswonger@...
V:910-892-8761
C:919-820-5473
-------------
NOTICE: The information contained in this electronic mail message is
intended only for the use of the intended recipient, and may also be
protected by the Electronic Communications Privacy Act, 18 USC
Sections 2510-2521. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please reply to the
sender, and delete the original message. Thank you.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Nighswonger | 2 Oct 13:50 2007

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

On 10/1/07, Chris Travers <chris.travers@...> wrote:
>
>
> On 10/1/07, Joshua D. Drake <jd@...> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Chris Travers wrote:
> > > On 10/1/07, Joshua D. Drake <jd@...> wrote:
> > >> -
> > >>
> > >> passwords will not be stored as plain text... they will be an encrypted
> > >> hash. I am not understanding the problem.
> > >
> > >
> > > Log in to LedgerSMB with your DB username and password.
> > >
> > > Click on a link.  How does the application know what password to use to
> log
> > > into the db?
> >
> > You hash and compare?
>
>
> Ok, maybe I am not being clear.
>
> To log in on the next page you need to provide PostgreSQL with a username
> and password.  How do we derive what password we send to PostgreSQL and
> where do we store this (it would have to be stored in the clear somewhere
> since we have to pass it via the DBI connect routine)?

Maybe hash it in the Java script (or whatever method you choose),
store the hash in a cookie, transmit the hash, have the code unhash
and pass the password to the DBI connect routine. Thus the only place
the password is in plain text is in the connect routine. (One must
wonder why the connect routine is not written to take hashed passwords
to begin with.)

Regards,
Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Seneca Cunningham | 2 Oct 14:23 2007
Picon

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

On Tue, Oct 02, 2007 at 07:50:43AM -0400, Chris Nighswonger wrote:
> On 10/1/07, Chris Travers <chris.travers@...> wrote:
> > To log in on the next page you need to provide PostgreSQL with a username
> > and password.  How do we derive what password we send to PostgreSQL and
> > where do we store this (it would have to be stored in the clear somewhere
> > since we have to pass it via the DBI connect routine)?
> 
> Maybe hash it in the Java script (or whatever method you choose),
> store the hash in a cookie, transmit the hash, have the code unhash
> and pass the password to the DBI connect routine. Thus the only place
> the password is in plain text is in the connect routine. (One must
> wonder why the connect routine is not written to take hashed passwords
> to begin with.)

Unhash the password?  I don't think you understand how password hashing
works.  When people hash passwords, they use one-way functions so that
it is infeasible to "unhash" it.  This means that we cannot unhash a
password from a cookie or form.  "Unhashable" techniques such as using
pack, ROT13, or conversion to an anagram are mere obfuscation.

As for the wondering on why DBI->connect does not take pre-hashed
passwords, if it did, that hash would effectively become a second
password for the database account.  One that, as a hash, people may be
more cavalier about than they would normally be.

--

-- 
Seneca
tentra@...

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Joshua D. Drake | 2 Oct 17:45 2007

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


Chris Travers wrote:
> On 10/1/07, Joshua D. Drake <jd@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Chris Travers wrote:
>>> On 10/1/07, Joshua D. Drake <jd@...> wrote:
>>>> -
>>>>
>>>> passwords will not be stored as plain text... they will be an encrypted
>>>> hash. I am not understanding the problem.
>>>
>>> Log in to LedgerSMB with your DB username and password.
>>>
>>> Click on a link.  How does the application know what password to use to
>> log
>>> into the db?
>> You hash and compare?
> 
> 
> 
> Ok, maybe I am not being clear.
> 
> To log in on the next page you need to provide PostgreSQL with a username
> and password.  How do we derive what password we send to PostgreSQL and
> where do we store this (it would have to be stored in the clear somewhere
> since we have to pass it via the DBI connect routine)?

Ahhh o.k. that makes more sense. Let me noodle.

> 
> Best Wishes,
> Chris Travers
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ledger-smb-devel mailing list
> Ledger-smb-devel@...
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

--

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
			UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


Gmane