[Catalyst] Storing a password hash with DBIC

[Brandon Black]

On 8/10/06, Jonathan Rockway <jon at jrock.us> wrote:
>
> Renaud Drousies wrote:
> > That's why the password should be mixed with a challenge string before
> > being hashed and sent over the network.
> >
>
> This is also not a good solution.  The server still needs to know some
> computable variant of the cleartext password in order for this to work.


The challenge/response variant I linked earlier in this thread avoids using
the cleartext password on the network, and does not allow for it to be
easily computable, either.

Feel free to hash passwords in your database so that if the database is
> compromised you don't just give out cleartext passwords.  This worked
> for UNIX's /etc/passwd for a while, but there's a reason they moved to
> shadow passwords.  Given a hash, cracking passwords is easy.


Well, given some hashes.  With modern /etc/shadow on linux having blowfish
instead of 1des its not so much an issue.  The shadowing thing is just to
add another layer of security on top of the existing solution.

The correct solution to the password issue is to use SSL.  For
> everything.  (Compromising the login cookie is just as good as a
> password, so you'd better transfer those over SSL too.)
>
> Anyway, we could go back and forth on how challenge/response hashes are
> "good enough", and I guess they are, but it's a lot *easier* to use
> strong cryptography and guarantee that your passwords aren't going to be
> compromised in band.  Just load mod_ssl into Apache, and you're done!
>
> (Someone could still brute force login attempts, but that's extremely
> easy to detect.   Again, think UNIX /etc/shadow.)
>

I'd agree that SSL is the best idea for solving a whole lot of issues, and
anyone authenticating over the net should be using SSL.  But SSL doesn't
make all of the other issues magically go away.  SSL is just yet another
layer of security.  Ideally, one should still be observing best practices
for challenge/response and translucent pw storage, etc, even within an SSL
environment.  That method I linked (and others like it) are still useful
under SSL, and are improved by SSL (because with signed certs it eliminates
MITM attacks that the challenge/response is otherwise subjected to -
assuming the javascript for the hashing and the login page itself are also
sent via SSL).

-- Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060810/2286c171/attachment.htm