[Catalyst] Storing a password hash with DBIC

Wade.Stuart at fallon.com Wade.Stuart at fallon.com
Thu Aug 10 21:39:24 CEST 2006







>

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

The points are three fold,

1,  You effectively (for the app involved) are giving the cleartext
password  -- even though it is hashed it is the string that is verified
server side, know the hashed string, know his password for your app...

2,  For other apps,  you now know the users hashed password (if like many
users he uses the same password for multiple sites).  Digest mode is
irrelevant,  this is easy to brute force (no salt -- one crack per string
test).

3,  You now effectively make your password database useful to any hacker --
they can become any user in your database without cracking their password
just by dumping your database's hash column.


The real lesson is,  if you need a secure login page and site, use SSL and
store your passwords server side hashed and salted with the most time
consuming digest available.  If you don't think about all of the
consequences (or if you are incapable of doing so) for whatever security
principles you are using,  you may be doing yourself more harm then not
implementing them at all.


>
> 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_______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/




More information about the Catalyst mailing list