[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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