

Ask HN: Sites using pop-up login windows without HTTPS? (e.g. Digg) - richesh

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.<p>The reason I'm asking is to figure out if we should be doing this for our startup. Any insight would be appreciated.<p>Here is a picture I took with FireBug showing Digg's login window:
http://farm3.static.flickr.com/2488/3674881101_b946ecf39f_o.png<p>Thanks in advance!
======
aditya
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.

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

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

------
richesh
Click-able link to the picture:
[http://farm3.static.flickr.com/2488/3674881101_b946ecf39f_o....](http://farm3.static.flickr.com/2488/3674881101_b946ecf39f_o.png)

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

