|
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 26 2010 07:26PM Dave Wichers (dave wichers aspectsecurity com) (1 replies) Re: At what layer to hash a password Jun 26 2010 11:13AM Tom Ritter (tom ritter vg) (1 replies) |
|
Privacy Statement |
the password in md5 (using javascript). Thats better than sending it
in plain/text. If you want double encrpytion, when the pass reach the
db, you could apply a salt to that md5
like md5("something_".$password);
On the negative side, crypting something larger than 32 chars to md5
will lead to collisions.
On Mon, Jun 21, 2010 at 10:06 AM, Robin Wood <robin (at) digininja (dot) org [email concealed]> 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.
>
> 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 ]