Re: At what layer to hash a password

[Robin Wood <robin () digininja org>]

On 26 June 2010 20:26, Dave Wichers <dave.wichers () aspectsecurity com> wrote:
> I would definitely recommend doing it only in one place. If all your
> 'password' setting/checking related code is in the application, I would
> do it there. If all this code is in stored procs in the DB, then I would
> do it there.
>
> Hopefully you have all your password management and use related code
> properly abstracted and managed in a single object or set of related
> objects for managing all of this.

This is one of the reasons I like the idea of doing the work at the
database layer, all data has to go through it so it all gets encoded
in the same way.

Using libraries is fine but I once came across an application that had
a web and application interface, both MD5'ed the password at the
presentation layer before passing it through, the problem we found was
the implementation of the MD5 on one of the interfaces was wrong so it
produced different hashes to what was expected so you could only log
in to the system on the interface you created the password on. This
means for multiple interface applications you would have to avoid
presentation layer encoding.

Robin

> -Dave
>
> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
> On Behalf Of Robin Wood
> Sent: Monday, June 21, 2010 9:06 AM
> To: webappsec () securityfocus com
> Subject: At what layer to hash a password
>
> 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.
>
> If you go for presentation layer then you could end up needing to
> update multiple areas of the code if you change the encoding method
> changes. You can pass this off to a function but in some situations
> you could still end up having to make multiple updates. The advantage
> of this layer is that the password is protected for its whole journey
> down the stack and into the database so even if it leaks in a debug or
> error log for example the plaintext isn't leaked. You could also have
> a problem if you use multiple different presentation layers keeping
> them all in sync and ensuring they all have the correct functionality
> to perform the encoding.
>
> At the other end if you do the encoding at the database layer then you
> only have a single point to change to update the algorithm so this is
> better from a coding point of view but there is the potential for the
> password to leak out on its way there.
>
> This leaves application layer, might be the best as you can pull all
> the setting calls into a single place but there is still chance of
> some leakage.
>
> I prefer the presentation layer from a security point of view but from
> clean coding I'd rather do it at database layer the same way I encode
> timestamps to what will go into the database at the last minute.
>
> What do other people think?
>
> Robin
>
>
>
> 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
> --------------------------------------



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