On 8/10/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
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.
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.
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
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
_______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
