Web Application Security
At what layer to hash a password Jun 21 2010 01:06PM
Robin Wood (robin digininja org) (5 replies)
RE: At what layer to hash a password Jun 28 2010 08:37PM
Niels Teusink (teusink fox-it com) (1 replies)
Re: At what layer to hash a password Jun 29 2010 04:46AM
Chris Travers (chris metatrontech com)
RE: At what layer to hash a password Jun 26 2010 07:26PM
Dave Wichers (dave wichers aspectsecurity com) (1 replies)
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.

-Dave

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]]
On Behalf Of Robin Wood
Sent: Monday, June 21, 2010 9:06 AM
To: webappsec (at) securityfocus (dot) com [email concealed]
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
--------------------------------------

[ reply ]
Re: At what layer to hash a password Jun 26 2010 07:29PM
Robin Wood (robin digininja org)
Re: At what layer to hash a password Jun 26 2010 05:02PM
Javier Bassi (javierbassi gmail com) (1 replies)
Re: At what layer to hash a password Jun 29 2010 04:43AM
Chris Travers (chris metatrontech com)
Re: At what layer to hash a password Jun 26 2010 02:36PM
Chris Travers (chris metatrontech com)
Re: At what layer to hash a password Jun 26 2010 11:13AM
Tom Ritter (tom ritter vg) (1 replies)
Re: At what layer to hash a password Jun 28 2010 08:55AM
Grega Bremec (gregab p0f net) (2 replies)
Re:Re: At what layer to hash a password Jun 29 2010 01:48AM
è?? (deco1987 126 com)
Re: At what layer to hash a password Jun 28 2010 02:17PM
Robin Wood (robin digininja org)


 

Privacy Statement
Copyright 2010, SecurityFocus