Ask HN: Sites using pop-up login windows without HTTPS? (e.g. Digg)
Am I missing something when I see sites like Digg not using HTTPS for login and passing plain text passwords? I thought you always needed HTTPS for login form submission.
The reason I'm asking is to figure out if we should be doing this for our startup. Any insight would be appreciated.
Here is a picture I took with FireBug showing Digg's login window: http://farm3.static.flickr.com/2488/3674881101_b946ecf39f_o.png
Thanks in advance! Not many people use https (security certificate hassles, etc.) for login, unless you really need it. Depends on the app right? For a bank it makes sense, for HN/Digg not so much. You're not technically required to use SSL for login forms, but it's a terrible idea not to. To say it's trivial to capture plain text login information might be the understatement of the millennium. It's basically a step up from not using any password at all. It can be tempting not to bother with an SSL certificate on a site that does not store personal information, but you're really doing a disservice to your users by not providing secure logins. When we designed our new layout, we looked around and saw that many sites who do the ajax login have a link to an ssl page - like this: http://www.flickr.com/photos/39989785@N07/3675346915/ We chose "Standard form | Secure form" as the verbiage but I've seen it several ways. Click-able link to the picture: http://farm3.static.flickr.com/2488/3674881101_b946ecf39f_o.... 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. 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. 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.
