[Catalyst] Storing a password hash with DBIC

Mark Blythe list at markblythe.com
Thu Aug 10 17:37:54 CEST 2006


I must be missing something here.

If you do the hashing on the client side, presumably that means your
form is posting the hashed password to the backend rather than the
plain text one.  That probably also means that the backend is taking
that hashed password and doing a simple check similar to:

if ($hashed_password_from_form eq $hashed_password_from_db) {
    access_granted();
}

How is that more secure than:

if (hash($plain_password_from_form) eq $hashed_password_from_db) {
    access_granted();
}

Even worse, with the client-side hashing solution, you're actually
storing on your servers the literal string that needs to be posted
over the wire to grant access.  Anyone who gains access to your
password store has struck instant gold.

My brain isn't yet fully awake this morning, so again, I could be
missing something.

On 8/10/06, Brandon Black <blblack at gmail.com> wrote:
>
>
>
> On 8/10/06, Christopher H. Laco <claco at chrislaco.com> wrote:
> > Jonas wrote:
> > > Hi,
> > > I'm trying to store an hashed password in a database using DBIC. What
> > > is the best way to create the digest of the password?
> > > I tried with deflate, but deflate only runs when the argument is a
> reference.
> > > Then i tried with an HTML::Widget Filter but the filter runs before
> > > the constraints, so the password failed to match with the confirm
> > > field.
> > > There are any other way of doing this without explicitly making the
> > > hash in the insert and update methods?
> > >
> > > Thanks,
> > > --Jonas
> >
> > http://search.cpan.org/dist/DBIx-Class-DigestColumns/
>
>
> Also, you could use something like:
>
> http://pajhome.org.uk/crypt/md5/sha1src.html
>
> And do your hashing in javascript in the browser.  Basically you want to
> hook onClick/onSubmit/whatever for your login form, and hash the contents of
> the passwd field before doing the actual submission, using a javascript sha1
> (or other algorithm of your choosing).
>
> Its much safer from a security standpoint to hash at the browser, as this
> prevents the user's cleartext password from being sent over the wire at all,
> and keeps your code/logs/employees from ever having a chance at knowledge of
> the actual password.
>
> -- Brandon
>
>
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo:
> http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>
>
>



More information about the Catalyst mailing list