Re: At what layer to hash a password

[Chris Travers <chris () metatrontech com>]

On Mon, Jun 21, 2010 at 6:06 AM, Robin Wood <robin () digininja org> wrote:
> When developing a web app using a presentation (html generation not
> browser side), application and database layer approach at what level
> should you encode a password that is on its way into a database? I'm
> generally thinking of hashing as the main encoding method but anything
> could be used.

This is a good question.  I think it depends on a large number of
things.  For my own applications I use a strategy I call "push
security back" which is a variation on the idea that applications
should have the least possible level of trust.  In this model,
permissions enforcement and authentication are handled by the lowest
tier I can use.  So normally I use native database accounts and have
the db library hash the passwords when the user is trying to log in.
There are, of course, some disadvantages to this approach (namely that
the password must be resubmitted in some way on every page request).
But on the whole it's better for the application to trust the db, but
not have the db trust the application (in this model, the application
doesn't actually have permission to do ANYTHING aside from what the
user's permissions are).  The main disadvantage, as you say, is that
accidental disclosure of passwords becomes a possible problem.  I
usually handle this by ensuring that passwords are essentially
isolated from the rest of the application, making it less likely for
an accident to disclose the password.

The other main place I'd consider putting the password hashing if I
could would be something like the way HTTP Digest Auth does it, where
a challenge/response relative to the client sends back a hash which is
then verified against a password plus some additional information.
However, this generally requires a high level of trust in your
application.

So the question is, where do you want to draw the trusted/untrusted border?

Best Wishes,
Chris Travers



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------