[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re-authentication proposal for LedgerSMB 1.3 (HTTP Auth)
- Subject: Re: Re-authentication proposal for LedgerSMB 1.3 (HTTP Auth)
- From: Seneca Cunningham <..hidden..>
- Date: Tue, 2 Oct 2007 08:23:41 -0400
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..