Ask HN: Why doesn't HN use SSL/HTTPS for its login form? | Hacker News Reader

Ask HN: Why doesn't HN use SSL/HTTPS for its login form?

54 pointsmatthodan48 comments

Just about everyone I ask tells me that it's best practice to implement SSL/HTTPS for any login page (to protect user passwords), but then I notice that HN doesn't use SSL/HTTPS for login. Am I missing something? Is it risky to use the HN login on public networks?

Sorry in advance if this has been covered before-- I did a quick search and didn't see any recent posts...

View on HN

It wouldn't be so bad except cookies aren't invalided when you change your password. I changed mine a few days ago, and didn't have to login again on any of my other computers. So once your cookie is sniffed, that person is you forever.

Probably one of these two:

1)HN is a side project for a busy man, and SSL/HTTPS simply isn't very high on the feature list.

2) Arc, the language HN is written in, doesn't support SSL/HTTPS

If you can't do it properly...

It's open source, you could always donate some of your own time to do it properly...

As jbyers said, it should be trivial to stick a webserver which supports SSL in front of the app. Perhaps it would be a good idea to modify the app to add the secure flag to the cookie it sets though.

Why do you care? I've already used Firesheep three times to downvote using your account.

I'll do it with this comment, too.

Cool, so what's your password then? Seeing as it doesn't matter if anyone finds it out...

I only care about your session. You can keep your password, unless I brute-force it from a 37signals webapp.

Ah, so you do care enough to not share your password. So I guess the reason I care about SSL is the same reason you care about SSL.

It should be straightforward to put HN behind an SSL proxy (nginx, apache, stunnel, what-have-you) if the application constructs URLs properly. HN seems to, but in some applications that's a big "if".

I'd be happy to test and supply an nginx 0.8 configuration if that would help.

once you login and the fact that you're logged in is passed around via a cookie, unless the entire interaction with the website is over HTTPS, the session can be hijacked in any wifi coffeehouse, rendering the limited usage of HTTPS mostly pointless.

The point is to prevent your actual password from being sent in the clear. Yes your session could still be hijacked, but most websites will at least require you to re-enter your password (over SSL) to change your key profile attributes or password, meaning the most someone can do with a hijacked session is vandalize the site from your account. If they have your password via sniffing, they can instantly do a whole lot more, especially if you use the same password everywhere, regardless of the merits of doing that.

I'll probably get slammed for this, but they do accept OpenID. Though that does nothing for session-jacking.

most websites will at least require you to re-enter your password (over SSL) to change your key profile attributes or password

While that is the case for most sites, HN doesn't require you to enter your current password when changing your password (or any other information for that matter).

You can hijack it in unprotected WiFi easily (e.g. firesheep), but even if it's protected, an attacker can use ARP poisoning to route all traffic to the attacker, and thus steal the sessions (and firesheep should still work in this case).

Are most/all common WiFi access points vulnerable to ARP poisoning?

As far as I know, all networks over a shared medium are vulnerable to ARP poisoning.

So in the old days, that was networks using hubs (instead of switches), these days it's wireless networks.

My understanding of the latest (WPA2) WiFi security is that each client creates a private channel with the access point – so it's totally up to the access point whether to trust, or route, anything any client says. That would suggest resistance to ARP poisoning is possible, at least. But I could be wrong, hence the question.

ARP poisoning is an inherent problem with the design of IP. There is no real defence against it, on any network that uses IP, regardless of what is running on the link layer (ethernet or any other 802.x protocol)

Just keep it under your hat lest someone put it into a firefox extension.

It's a social news site low risk target for that sort of thing. When it started the aggregate tech level was high enough that pretty much everyone knew to use a different password on each site as a best practice. Now not so much. In any event he was busy and decided that it was a low enough risk for the password to be sent in the clear as the damage that could potentially be caused is low. (a few bunk comments, changing the email address/password, etc....) At least that is what I recall him posting here before when this question came up before.

  > It's a social news site low risk target for that sort of thing.