Re: At what layer to hash a password

[arvind doraiswamy <arvind.doraiswamy () gmail com>]

Apologies for a very delayed reply. Here are my thoughts. The key
point is - Why are you hashing data? To ensure its confidentiality.
Now, data can be in clear text at the client, anywhere in between or
even at the database. So my call is to encrypt it everywhere. Hold on
I'll explain ;)

a) At the client: Your main threat here is local access. If the app is
public and people might access it from a public computer, there's a
chance they might be able to steal it from the RAM. So some Javascript
with a salted implementation of MD5 should work well here. The salt
should be random though, otherwise you could just replay the MD5
password and gain access..and you're back to square 1.

b) The hashing on the client automatically then forces you to have
passwords hashed in your database as well. This is due to the hash
being irreversible. So when the salted hash(with the password) is sent
to the application server, it decrypts it partially and is left only
with the MD5(Insert hashing algorithm here). This MD5 is then compared
against the hashed DB password and access then granted.

To sum up:
1) Client side salted MD5 - No plaintext ever
2) App has salt stripping code - No plaintext ever, only MD5
3) DB has hashed passwords - Compares against hash always

That sounds ok to me. And no, I'm not a developer so I'd love to hear
if this is overkill from a performance point.

Cheers
Arvind



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