webappsec@securityfocus.com
[Top] [All Lists]

RE: At what layer to hash a password

Subject: RE: At what layer to hash a password
From: Niels Teusink
Date: Mon, 28 Jun 2010 22:37:54 +0200
As I see it you have three options: on the client in javascript, in the 
application or in the database

On the client seems nice, but there are both advantages and disadvantages
+ you hash the password before it's even sent to the server, so the server 
never actually has the plaintext password
- you'll have to implement some challenge/response scheme, or the password can 
simply be replayed
- if you implement challenge/response, your client has to do something like 
this: hash(hash($password+$salt)+$challenge). This means that an attacker could 
authenticate with hash($password+$salt) instead of the password, which is the 
thing that is stored in your database (passing-the-hash attack) and the 
attacker won't have to the passwords to authenticate as a user if he 
breaks into the database
- some people use it as an SSL alternative but it's not a very good one (a 
skilled attacker in a MITM position just grabs the session cookie or changes 
the javascript on-the-fly to submit the plaintext password as well). It does 
offer some protection from passive sniffing though
- needs javascript to be enabled

In the application
+ it's easy and you can hash the password just after receiving it
- your application still receives the password in plaintext, it temporarily 
ends up in memory in lots of places (but an attacker will probably modify your 
app instead of going through RAM)

In the database
+ one system for all your applications (but if you want to change the algorithm 
you run into problems with existing passwords anyway)
- you have to do something like UPDATE users SET password = 
MYHASH('plaintextsecretpass'||salt) WHERE id=1 and your password will end up 
plaintext in your database logs.

I tend to do it in the application just after receiving the password. I really 
like the approach of native database accounts as well, but you'll have to store 
the plaintext password (or a connection handle if you can) in the user session.

No perfect solution I guess :) (especially if you have the multiple interfaces 
thing to take into account)

Niels

-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx [mailto:listbounce@xxxxxxxxxxxxxxxxx] On 
Behalf Of Robin Wood
Sent: maandag 21 juni 2010 15:06
To: webappsec@xxxxxxxxxxxxxxxxx
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
--------------------------------------

<Prev in Thread] Current Thread [Next in Thread>