[unfug]

I haven't verified that Digg does this, but most big sites that do logins over http do some sort of hashing on the client side so that the actual password isn't sent plaintext.

As has been mentioned, there are all sorts of issues with using https, and for sites where security isn't a huge concern (it's always important, but not as much for a site like HN vs. a bank), hashing client side and sending the data over plain http can be enough.

[jm4]

Hashing the password client side and then sending it in plain text does nothing. In that case you don't need the password to log in; you only need the hash. Intercept the username and hash over an HTTP connection and then impersonate that user. It makes no difference to the person stealing accounts and only means more work for the hapless developer who thinks this is some form of security. You'd be better off doing nothing. It's just as secure (or rather insecure) and less work.

[unfug]

I greatly over-simplified the algorithm in my initial post, but there are advantages to a straight hash of the password.

Even if you can intercept the person's hash and login to that site, you still don't know the user's original plaintext password. A lot of people re-use the same password throughout many (or all) of their online accounts. The attacker may be able to impersonate the user for the current site, but they don't have their actual password to gain access to other sites.

What I was talking about in my original post (but didn't properly explain) was using hashing as part of a larger algorithm for doing a challenge/response login. The idea is explained here: http://pajhome.org.uk/crypt/md5/auth.html

I agree that HTTPS is the way to go if security is a huge concern (like for banks), but for a simpler site you could get away with using CHAP and still provide a reasonable level of security.